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ABSTRACT 


This  thesis  was  undertaken  to  examine  the  post- development 
process  of  verifying  the  correctness  of  software  programs, 
specifically  to  evaluate  the  effectiveness  and  practicality  of 
several  proposed  methods  of  verification.  Of  interest  were  the 
degree  to  which  utilization  of  a given  method  can  be  said  to 
demonstrate  correctness  and  the  feasibility  for  general  use  of 
that  method.  The  method  of  research  was  to  study  current 
literature  concerning  software  testing  and  formal  proofs  of 
correctness,  select  a we 11 -documented  program  of  intermediate 
size  for  experimentation,  apply  selected  verification  methods 
to  that  program,  and  finally  to  compare  the  results  of  the 
several  experimental  demonstrations  of  correctness.  The 
experiments  conducted  included  a proof  of  correctness  and 
dynamic  testing  with  test  data  cases  selected  by  a condition 
table  method,  by  path  analysis,  and  by  structural  decomposition 
of  the  program. 
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I.  INTRODUCTION 

This  first  chapter  reviews  the  environment  in  which  software 
verification  methods  are  employed  and  presents  generally  accepted 
definitions  and  descriptions  of  software  testing. 

A.  THE  SOFTWARE  PREDICAMENT 

1 . Scope  of  Software  Development 

Ware  Myers  has  characterized  the  current  state  of  expanding 
programming  applications  as  a serious  software  predicament  (28) . 
The  cost  of  computer  hardware  has  declined  significantly  over 
the  last  decade,  making  more  and  more  applications  feasible  for 
automation.  In  1973  it  was  estimated  that  between  $15  and  $25 
billion  were  being  spent  annually  on  software  development  and 
maintenance  (3).  The  Depax’tment  of  Defense  spent  about  $3  billion 
in  1976  on  computer  software  (34)  , and  has  been  doubling  the 
number  of  functions  performed  by  software  every  few  years, 
primarily  in  converting  weapons  systems  components  from  analog 
to  digital. 

2 . Problems  in  Software  Development 

Unfortunately  for  the  growing  user  communities,  and 

despite  the  expectations  raised  with  the  advent  of  modern  pro- 
gramming practices  (MPP) , all  is  not  well  with  software 
development. 

a.  Our  ability  to  estimate  time  and  resources  required 
for  the  design  and  development  of  software  has  not  appreciably 
increased. 

b.  Most  major  software  projects  have  required  that 
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special  support  tools  be  developed,  that  new  automated  testing 
aids  be  generated,  or  that  a new  language  capability  be  acquired; 
in  short,  there  is  inadequate  transfer  of  technology  between 
projects  within  single  organizations,  and  even  less  among  organi- 
zations . 

c.  An  unreasonable  share  of  software  effort  has  been 
expended  on  maintenance  of  existing  programs.  Estimates  of  75% 

or  more  of  a company's  programming  effort  being  devoted  to  mainte- 
nance have  not  been  uncommon. 

d.  The  rate  of  increase  in  programmer  productivity  has 
not  kept  pace  with  the  introduction  of  improved  management  and 
programming  methodologies,  let  alone  with  the  rapidly  increasing 
hardware  capabilities;  in  fact,  we  are  still  struggling  to  learn 
to  measure  this  productivity. 

e.  The  quality  of  software  has  been  less  than  desired. 
While  there  is  no  agreement  on  how  to  quantify  the  quality  of 
software,  many  shortcomings  are  apparent  (4):  software  is  still 
difficult  to  read,  understand  and  modify;  programs  are  frequently 
hard  to  use  .properly  and  easy  to  misuse;  they  are  often  lacking 
in  sufficient  generality  to  be  used  in  several  applications  or 
transported  to  different  machines;  and  program  reliability  has 
been  disappointing. 

The  applications  planned  for  automation  require  bigger  and 
more  complex  systems  than  ever  before.  Dijkstra  pointed  out 
that  complex  systems  which  are  perhaps  one  thousand  times  larger 
than  existing  system  cannot  be  constructed  with  the  same 
techniques  used  to  compose  the  smaller  systems;  order-of -magnitude 


leaps  in  scale  cannot  be  treated  as  gradual  increases  that  can 
be  handled  by  simple  induction  (10) . A systematic  and  scientific 
method  to  accomplish  functions  of  such  magnitude  is  required. 

Improvements  in  the  reliability  of  software  (the  extent 
to  which  programs  can  be  expected  to  satisfactorily  perform 
their  intended  functions)  are  desired  without  incurring  the 
staggering  costs  of  totally  exhaustive  testing.  That  reliability 
needs  improvement  seems  obvious.  The  relative  level  of  program- 
ming effort  devoted  to  maintenance  of  existing  programs  bears 
testament  to  the  existence  of  errors  in  programs  presumably 
tested  and  certified  correct  prior  to  their  release  for  use. 

Even  diligent  application  of  the  modern  programming  practices 
by  talented  programmers  has  not  necessarily  produced  reliable 
software.  Gerhart  and  Yelowitz  (15)  identified  errors  in  pro- 
grams that  were  published  to  demonstrate  these  MPP,  errors  in 
specifications,  in  construction,  and  in  programs  formally 
"proven"  correct! 


B.  SOFTWARE  ENGINEERING 
1 ► Current  Trends 

A discipline  has  arisen,  referred  to  as  software  engi- 
neering, which  draws  from  established  principles  of  science 
and  engineering  in  attempting  to  formally  define  a systematic 
approach  to  software  development.  While  the  goals  of  this 
discipline  are  broad  in  scope,  the  application  of  software 
engineering  toward  attainment  of  correct  software  is  of 
particular  interest. 
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Recent  trends  in  software  engineering  have  emphasized  the 
role  of  design  and  implementation  in  preventing  errors  over 
the  role  of  testing  to  detect  errors  for  correction.  These 
techniques  include: 

a.  More  thorough  analysis  and  definition  of  requirements: 
The  lack  of  adequate  system  specifications  has  been  a major 
cause  of  software  shortcomings  (12) . 

b.  Modular  design  of  programs. 

c.  Top-down  design  and  implementation  techniques. 

d.  Management  practices  such  as  the  use  of  the  team 
concept  (possibly  including  the  chief  programmer  team  concept), 
project  workbooks,  formal  documentation  requirements,  formal 
and  peer  review,  and  structured  walkthrough  of  code. 

e.  Structured  programming:  This  concept  is  at  the  core 
of  modern  programming  practices.  While  many  managers  complain 
that  they  encounter  resistance  in  implementing  structured  pro- 
gramming in  their  organization  (5) , there  is  growing  data  to 
support  the  proposition  that  structured  programming  techniques 
can  produce  more  reliable  and  more  cost  effective  software 
systems  (28) . 

2 . Need  for  Post -Development  Testing 

The  experience  of  the  research  reported  in  later  chapters 
of  this  thesis  confirmed  the  need  for  greater  relative  emphasis 
on  design  and  implementation  techniques  as  compared  to  verifi- 
cation techniques.  Much  of  the  process  of  constructing  a formal 
proof  of  correctness  of  the  sample  program  selected  for  experi- 
mentation was  clearly  a duplication  of  the  design  and  implementation 
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effort;  it  was  necessary  to  analyze  the  completeness  and  con- 
sistency of  the  program  specifications,  verify  the  particular 
modular  design  selected,  justify  the  control  flow  of  each  pro- 
cedure, and  determine  the  reasoning  behind  the  choice  of 
particular  stopping  criteria  for  program  loops.  To  a somewhat 
lesser  extent  the  same  was  true  of  the  most  rigorous  of  the 
dynamic  testing  strategies  employed  (Chapter  III,  Section  C) . 
The  duplication  of  effort  is  simply  not  cost  effective. 

The  successful  and  widespread  use  of  as  yet  undeveloped 
techniques  that  will  ensure  development  of  correct  software 
programs  lies  many  years  ahead.  For  the  foreseeable  future, 
programs  under  development  will  need  to  be  subjected  to  an 
effective  and  practical  ex  post  facto  verification  process. 
Diligent  application  of  existing  program  testing  techniques  has 
been  shown  to  enhance  the  software  development  process  (1,2,6). 
Significant  efforts  are  required  in  applying  the  discipline  of 
software  engineering  toward  refinement  or  replacement  of  the 
verification  methods  now  in  use. 


C.  DEFINITIONS  IN  SOFTWARE  TESTING 

Methods  of  testing  or  proving  the  correctness  of  software 
have  been  developed  until  quite  recently  on  an  ad  hoc  basis,  to 
fill  particular  needs  in  the  field  rather  than  to  build  a 
complete  scientific  model  for  the  verification  process.  The 
terms  used  to  describe  the  activities  involved  in  demonstrating 
correctness  have  likewise  evolved  sporadically.  The  following 


definitions  are  widely  but  not  universally  accepted. 


1. 


The  central  issue  in  software  testing,  verification, 
validation,  or  similar  terms  is  a demonstration  that  the  software 
at  hand  is  correct;  i.e.,  that  the  given  software  system  produces 
the  intended  results.  The  assertion  that  a program  is  correct 
is  in  effect  a statement  that  it  performs  precisely  those  func- 
tions, and  only  those  functions,  called  for  in  its  specifications, 
and  furthermore  that  its  specifications  are  an  accurate  repre- 
sentation of  a design  suitable  to  satisfy  the  intended  require- 
ment. The  term  "correctness"  has  a connotation  inclusive  of  and 
stronger  than  the  notion  of  reliability  of  software,  which  was 
defined  earlier  as  the  extent  to  which  programs  can  be  expected 
to  satisfactorily  perform  their  intended  functions.  A thorough 
demonstration  of  correctness  involves  more  than  showing  that  a 
program  satisfies  some  written  specifications;  it  involves  an 
analysis  of  the  completeness,  clarity,  and  consistency  of  the 
specifications  as  well. 

2 . Debugging 

This  term  has  frequently  been  used  synonymously  with 
testing,  but  should  be  distinguished  in  the  following  sense: 
testing  is  a process  to  uncover  errors,  while  debugging  begins 
when  an  error  has  been  detected  and  is  the  process  of  isolating 
and  correcting  these  known  errors.  A succinct  statement  of  this 
distinction  is: 

When  debugging  is  completed  the  program  definitely 
solves  some  problem.  Testing  seeks  to  guarantee 
that  it  is  the  problem  that  was  intended  (18) . 


3.  Testing 

Testing  has  just  been  distinguished  from  debugging.  In 
Reference  24  five  major  activities  in  testing  were  defined,  using 
the  terms  most  commonly  accepted  in  practice: 

a.  Verification  is  the  process  of  establishing  logical 
correctness  of  a program  (i.e.,  correspondence  with  formal  require- 
ments) in  a test  environment.  Verification  is  typically  accom- 
plished by  actual  program  execution  using  selected  test  data. 

This  process  of  dynamic  execution  is  the  single  activity  most 
often  intended  by  use  of  the  general  term  testing. 

b.  Validation  is  the  process  of  establishing  logical 
correctness  in  some  given  external  environment,  although  not 
necessarily  in  the  operational  environment. 

. c.  Proving  is  the  mathematical  establishing  of  logical 
correctness  without  regard  to  the  environment;  it  does  not 
involve  program  execution. 

d.  Certification  is  an  organizational  endorsement  that 

a program  meets  certain  standards  of  correctness  and  effectiveness 
in  a useful  environment. 

e.  Performance  testing  is  the  demonstration  of  non- 
logical  properties,  usually  execution  timing  and  throughput 
capability. 

4 . Verification  and  Validation 

Verification  and  validation  is  a currently  popular  term 
used  to  describe  the  processes  involved  in  testing  software 
prior  to  user  acceptance;  used  as  such  the  term  actually  encom- 
passes to  some  degree  all  five  of  the  above  testing  activities 
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(with  the  frequent  exception  of  proving). 

5 . Scales  of  Testing 

During  the  development  and  operation  of  a software  system, 
differing  scales  of  testing  must  be  performed.  Traditional 
scales  of  testing  are  unit  testing,  integration  testing,  and 
regression  testing. 

a.  Unit  Testing 

Unit  testing  is  the  testing  of  the  independent  modules 
comprising  the  functional  decomposition  of  a large  system.  Testing 
at  the  unit  level  involves  examination  of  the  internal  logic  of 
the  module  to  ensure  that  the  module's  effects  on  the  larger 
program  containing  it  are  consistent  with  those  effects  required 
by  the  specification,  and  verification  of  the  assumptions  made 
within  the  module  about  the  larger  program.  Because  specifications 
are  frequently  ambiguous,  unit  testing  often  results  in  reexami- 
nation of  the  unit  specification. 

The  two  methods  employed  in  unit  testing  are  functional 

. 

(black-box)  tests,  which  are  based  on  no  knowledge  of  the  inter- 
nal structure  of  the  program,  and  logical  tests  which  are  based 
on  program  structure.  Selection  of  test  data  which  are  appro- 
priate  for  an  ideal  test  (as  described  in  Chapter  II,  Section  A) 
is  difficult  or  impossible  for  black-box  testing  because  it  is 
impossible  to  distinguish  data  that  are  treated  similarly  or 
differently  internal  to  the  black-box.  Therefore  program  veri- 
fication tests  by  the  developer  are  nearly  always  based  on  pro- 
gram structure.  Acceptance  testing  by  the  user  is  generally 
functional  in  nature  of  necessity. 
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b.  Integration  Testing 


Integration  testing  is  conducted  to  determine  the  extent 
to  which  a system  meets  its  specifications  in  an  environment 
similar  to  its  working  environment.  The  focus  of  integration 
testing  is  on  module  interaction  as  opposed  to  internal  module 
operations.  When  unit  testing  has  been  conducted  thoroughly 
beforehand,  integration  testing  is  primarily  a verification  that 
modules  do  not  modify  those  relationships  in  the  environment 
that  the  specification  states  must  be  preserved  (e.g.,  that  pro- 
tected portions  of  memory  have  not  been  affected  and  that  global 
variables  have  not  been  modified  in  an  undesirable  or  unantici- 
pated manner),  and  a thorough  test  of  the  consistency  of  .the 
specification  itself.  Were  the  techniques  of  Eormal  definition 
of  requirements  and  automated  verification  of  specifications 
more  developed,  integration  testing’  would  be  less  than  the 
crucial  and  expensive  effort  it  so  often  has  become. 

The  relationship  between  unit  and  integration  tests  is 

formalized  by  the  following  theorem  which  is  the  basis  for 

demonstrating  the  correctness  of  software  by  testing  or  proving: 

If  it  can  be  demonstrated  that  each  module  in 
a system  meets  its  specifications  assuming  only 
that  all  submodules  meet  their  specifications, 
then  the  entire  system  is  correct  (16). 

It  should  be  noted  that  the  demonstration  required  by  the 
above  statement  is  essentially  a verification  that  the  inter- 
actions of  modules  are  consistent  with  the  specifications. 

There  is  controversy  over  the  best  strategy  for  sequencing 
unit  and  integration  tests.  The  classical  strategy  of  bottom-up 
testing  proceeds  from  unit  to  integration  tests  as  lower-level 
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modules  are  completed,  and  requires  test  program  drivers  to  run 
lower-level  module  tests  until  the  calling  modules  are  ready  to 
be  incorporated.  Common  criticisms  of  this  strategy  are  the 
duplication  of  effort  in  writing  driver  programs,  the  cost  in- 
volved since  execution  of  higher-level  modules  involves  reexecu- 
tion of  the  lower  modules,  and  most  severely  the  fact  that  inte- 
gration errors  if  present  are  discovered  at  a late  stage  in 
development,  thus  inflating  the  cost  of  their  correction. 

The  top-down  testing  strategy  is  much  heralded  as  an  integral 
part  of  the  top-down  design  technique,  but  it  is  little  practiced 
Its  benefits  are  purported  to  be  the  early  detection  of  specifi- 
cation errors  relating  to  interfacing,  since  the  high-level  pro- 
gram skeleton  is  coded  and  executed  first,  with  simple  dummy 
programs  required  as  sub-program  stubs.  These  stubs  are  to  be 
replaced  by  the  actual  lower-level  modules  as  they  are  written, 
thus  facilitating  the  check-out  of  new  modules  one  at  a time 
while  continually  verifying  the  correctness  of  module  interfaces. 
In  introducing  the  concept  of  a built-in  package  of  "test  pro- 
cedures" deliverable  with  a software  product,  Panzl  contends 
that  neither  of  the  above  goals  are  well  served  by  the  top-down 
strategy  (30).  He  states  that  top-down  testing  discourages 
thorough  testing  of  lower- level  modules  because  they  are  never 
executed  directly;  in  fact,  it  is  often  difficult  to  find  an 
input  data  combination  that  will  force  execution  of  a desired 
submodule. 

In  practice  a mix  of  top-down  and  bottom-up  strategies  has 
been  used.  Unfortunately,  a common  choice  of  strategies  is  to 
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defer  all  testing  until  the  entire  system  can  be  tested.  This 
all-at-once  strategy  is  costly  in  execution  time  because  all 
modules  must  always  be  present,  and  costly  in  effectiveness  be- 
cause the  intellectual  task  of  isolating  errors  is  greatly  magni- 
fied when  a systematic  strategy  is  missing.  However,  it  is  the 
most  prevalent  testing  strategy  today  (30).  In  fact,  the  experi- 
ments in  testing  and  proving  which  are  reported  in  the  following 
chapters  of  this  thesis  were  performed  in  an  all-at-once  fashion 
by  virtue  of  the  fact  that  a program  which  had  completed  develop- 
ment was  the  subject  of  the  experiments.  Even  so,  elements  of 
bottom-up  testing  were  apparent  in  several  of  the  strategies  used, 
c.  Regression  Testing 

Regression  testing  is  the  reverification  and  revalidation 
of  software  after  adding  new  capabilities  or  after  performing 
maintenance  to  correct  errors  discovered  in  operation.  Its 
purpose  is  to  verify  that  the  desired  modification  and  none  other 
has  been  made.  Regression  testing  has  until  recently  received 
very  little  formal  attention  (12)  , which  is  puzzling  in  light 
of  the  previously  mentioned  estimates  of  the  percentage  of 
programming  effort  devoted  to  maintenance.  A simple  management 
technique  to  enhance  regression  testing  is  to  ensure  that  the 
test  cases  produced  during  development  testing  are  collected 
and  documented  as  a package,  and  maintained  to  be  reexecuted 
after  maintenance.  If  extensive  maintenance  is  performed,  addi- 
tional analysis  of  the  thoroughness  of  test  achieved  with  the 
saved  data  should  be  conducted.  While  the  test  procedures 
suggested  by  Panzl  (30)  add  to  the  effort  of  development,  their 
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value  at  regression  test  time  merits  careful  consideration  of 


D.  APPROACHES  TO  DEMONSTRATING  CORRECTNESS 


As  suggested  earlier,  testing  is  a discipline  that  has  been 
learned  through  application,  with  little  formal  basis  until 
very  recently.  The  first  major  collection  of  testing  concepts 
resulted  from  a 1972  conference  at  the  University  of  North 
Carolina,  the  proceedings  of  which  were  published  in  book  form 
by  W.  C.  Hetzel  (18).  The  first  significant  attempt  to  establish 
a mathematically-based  theory  of  program  testing  was  a paper  by 
John  B.  Goodenough  and  Susan  L.  Gerhart  (17);  this  theory  is 
discussed  in  Chapter  II. 

In  the  development  of  testing  methods,  two  complementary 
approaches  arose,  static  analysis  and  dynamic  testing.  Methods 
that  have  been  employed  in  an  attempt  to  show  correctness  have 
ranged  from  purely  static  (e.g.,  formal  proof  of  correctness) 
to  purely  dynamic  (e.g.,  execution  of  the  programs  with  randomly 
selected  test  data) , although  usually  a combination  of  the  two 
approaches  has  been  used. 

1.  Static  Analysis 


a.  Capabilities 

Static  analysis  refers  to  a wide  range  of  activities 
that  can  be  performed  without  program  execution  (although  more 
and  more  such  activities  involve  automated  analysis  of  source 
programs  by  software  tools) . Quite  often  static  analysis  is 
perfomred  prior  to  live  testing  to  help  in  test  planning  and 
test  data  preparation.  The  technique  can  in  itself  detect  errors 
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in  logic  (such  as  uninitialized  variables)  and  questionable 
software  practices  (such  as  initialized  but  never  referenced 
variables).  It  can  also  be  used  as  a means  of  enforcing  pro- 
gramming standards. 

The  most  familiar  form  of  static  analysis  is  program  checking, 
or  desk  checking.  While  automated  static  analysis  techniques 
of  significant  capability  are  being  developed,  thorough  desk 
checking  is  still  an  efficient  method  for  insuring  software 
correctness.  When  formalized  by  management  in  effective  peer 
review  or  structured  walkthrough  policies,  program  checking  is 
"very  effective"  in  reducing  errors  (1) . Program  checking  can 
detect  syntax  errors,  undeclared  variables,  unreachable  program 
segments,  etc. 

Directed  graphs  of  program  control  flow  and  data  flow  are 
common  tools  of  static  analysis,  and  are  the  basis  for  the  path 
analysis  techniques  of  dynamic  testing.  Graphs  of  data  flow 
lend  themselves  to  detection  of  errors  in  initialization  and 
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referencing  of  data.  Control  flow  graphs  provide  visual  evidence 
of  program  adherence  to  structured  programming  practices  and 
offer  several  measures  of  program  complexity.  Considerable  study 
of  the  relationship  between  program  structure  and  complexity 
and  resultant  error  characteristics  has  been  conducted  at  the 
Naval  Postgraduate  School  (most  recently  reported  in  Ref.  33). 

A strong  relationship  has  been  found  to  exist  between  complexity 
and  errors,  suggesting  that  complexity  measures  may  be  used  to 
establish  programming  standards  (note  that  constructs  of 
structured  programming  have  lower  complexity  measures  than 
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non-structured  constructs)  and  to  indicate  how  to  allocate 
scarce  testing  resources. 

b.  Automated  Aids 

Particularly  when  dynamic  testing  is  to  be  performed 
with  the  number  of  paths  tested  as  a criterion,  static  analysis 
techniques  are  used  to  aid  in  developing  test  cases,  frequently 
by  automation.  Fairley  (12)  suggests  that  static  analysis 
algorithms  (including  cross-reference  tables,  numbers  of 
occurrence  of  statement  types,  number  of  subprogram  calls,  graph 
analysis,  etc.)  can  and  should  be  included  in  compilers. 
Ramamoorthy  et  al.  (32)  discuss  the  techniques  and  problems 
involved  in  automated  generation  of  test  data  inputs  selected 
to  satisfy  varying  requirements  for  coverage  of  the  branches 
of  a program  graph,  and  describe  a prototype  generator  included 
in  their  Fortran  Automated  Code  Evaluation  System  (FACES) . 

c.  Limitations 

Whether  test  data  is  generated  manually  or  by  auto- 
mated means,  there  is  unfortunately  no  reliable  way  of  automating 
the  computing  of  the  correct  output.  Needless  to  say,  dynamic 
testing  presupposes  a known  (or  at  least  bounded)  output,  and 
specifications  must  be  available  for  each  program  tested.  A 
limitation  in  the  degree  of  testing  which  is  feasible  is  fre- 
quently imposed  by  the  difficulty  of  determining  the  desired 
output. 

A serious  limitation  of  static  analysis,  and  particularly 
of  test  case  generators,  is  the  decidability  problem  (12). 
Algorithms  may  be  easily  written  to  identify  all  syntactic 
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paths  of  control  flow  in  a program,  but  it  is  not  possible  to 
algorithmically  determine  the  semantic  paths  (those  syntactic 
paths  which  can  in  fact  be  executed  for  some  set  of  input  data) . 
Therefore  it  is  not  possible  for  all  programs  to  determine 
whether  some  statements  (including  termination  statements)  can 
be  executed  for  any  input  data.  In  these  cases  dynamic  testing 
or  the  more  difficult  techniques  of  symbolic  execution  or  proofs 
of  correctness  are  often  used  to  decide  the  question. 


2. 


Dynamic  testing  is  the  process  of  actual  program  execu- 


tion to  provide  evidence  upon  which  some  conclusion  may  be 
reached  as  to  the  correctness  of  the  software.  Applications 


of  theoretically-based  testing  methods  (as  described  in  Chapter 
II)  have  not  yet  countered  Dijkstra's  pronouncement  that  "Program 


testing  can  be  used  to  show  the  presence  of  bugs,  but  never  to 
show  their  absence!"  (10).  Nonetheless,  dynamic  testing  has 
been  and  will  remain  the  most  common  evidence  proffered  to  show 
program  correctness  or  reliability, 
a.  Selecting  Test  Cases 

The  critical  activity  during  dynamic  testing  is  the 
selection  of  test  cases.  Intuitively  it  is  desirable  to  select 
a set  of  test  cases  which  are  representative  of  the  actual  input 
domain  the  program  will  have  to  contend  with  during  operation. 
The  principle  guide  in  selecting  test  cases  has  been  to  test 
for  the  likely  kinds  of  errors  in  the  program,  particularly  in 
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possible  errors,  it  is  unlikely  that  this  principle  alone  can 
be  relied  on  to  select  a suitable  set  of  test  data.  Selection 
of  a data  set  truly  representative  of  the  input  domain  is  parti- 
cularly difficult  without  knowledge  of  the  internal  structure 
of  the  program  (i.e.,  when  doing  black-box  testing),  because  it 
is  then  impossible  to  distinguish  data  that  are  treated  similarly 
internally.  Knowledge  of  the  program  structure  can  be  used  to 
identify  the  complex  portions  of  the  program  which  should  be 
subjected  to  the  most  thorough  testing,  and  to  help  identify 
the  groups  of  data  that  are  handled  similarly  and  thus  aid  in 
selecting  those  cases  representative  of  certain  subsets  of  the 
input  domain.  However,  use  of  this  knowledge  is  of  limited  value 
in  that  there  is  no  certainty  that  the  program  structure  is  a 
correct  representation  of  the  conditions  required  for  correct 
operation  of  the  program  (16) . 

b.  Thoroughness  of  Tests 

The  thoroughness  of  test,  or  degree  of  test  coverage, 
is  intended  to  provide  a measure  of  the  reliability  of  the 
testing  process.  The  more  thorough  the  test,  the  less  probable 
that  undetected  errors  remain.  Unfortunately,  no  perfect  quanti- 
tative measure  of  test  thoroughness  has  been  recognized,  although 
it  is  clear  that  the  criteria  used  to  select  test  cases  will 
determine  the  thoroughness  of  test. 

Typically,  estimates  of  test  thoroughness  have  been  based 
on  a count  of  the  source  statements  executed  or  the  program 
control  paths  traversed.  While  a test  which  causes  the  execution 
of  all  program  source  statements  may  appear  thorough,  there  are 





numerous  counterexamples  which  demonstrate  the  actual  lack  of 
thoroughness  (for  example,  in  Ref.  22).  Since  there  are  typically 
an  infinite  number  of  possible  sequences  of  statement  execution, 
any  finite  tests  which  execute  each  program  statement  at  least 
once  cannot  be  said  to  have  tested  all  possible  sequences,  and 
thus  may  fail  to  reveal  all  program  errors.  The  path  analysis 
strategy  of  dynamic  testing  involves  execution  of  selected  con- 
trol flow  paths  in  the  program  under  test.  Because  the  number 
of  control  flow  paths  may  be  very  large  or  infinite  (due  to  the 
presence  of  loops) , practical  path  analysis  strategies  are 
limited  to  execution  of  some  subset  of  the  total  paths.  Huang 
^defined  a "minimally  thorough"  test  as  one  which  caused  at  least 
one  traversal  of  every  branch  or  arc  in  the  program's  control 
flow  graph  (flowchart)  (22)  ; however,  such  a test  cannot  assure 
detection  of  all  errors.  In  fact  there  is  no  agreement  as  to 
what  an  adequate  measure  of  thoroughness  may  be  (traverse  each 
arc  twice,  traverse  all  possible  arc  pairs,  etc.).  Nonetheless, 
it  has  been  shown  that  for  many  programs  (65%  of  a small  survey 
of  eleven  programs  conducted  by  Howden) , path  analysis  criteria 
are  "almost  reliable"  (21).  Given  the  alternatives,  testing 
based  on  path  analysis  is  today  a sound  choice,  particularly 
when  accompanied  by  careful  program  checking  and  a structured 
walk-through  of  the  design  itself. 

The  discussion  in  Chapter  II  of  a theory  of  testing  further 
examines  the  critical  matter  of  thoroughness  of  tests, 
c.  Automated  Aids 

Automated  aids  to  support  dynamic  testing  include 


the  experimental  test  case  generators  discussed  in  the  section 
on  static  analysis,  and  programs  which  compute  the  degree  of 
coverage  of  the  program  graph  according  to  the  given  path  analysis 
criterion.  Pimont  and  Rault  (31)  describe  an  implementation  of 
such  a technique,  with  a more  ambitious  coverage  criterion  than 
most  of  the  path  analysis  techniques. 

The  insertion  of  software  counters  in  the  target  branches, 
a relatively  simple  form  of  program  instrumentation  for  testing, 
assists  in  test  data  selection  by  providing  feedback  as  to  the 
coverage  obtained  from  each  set  of  input  data  (22,  23).  A common 
form  of  program  instrumentation  is  the  use  of  assertion  statements 
expressing  the  relationships  among  data  which  should  hold  at 
various  nodes  in  the  program.  During  execution  the  assertions 
are  evaluated  to  check  their  validity.  Program  instrumentation 
can  also  be  used  to  perform  data  flow  analysis  by  setting  state 
flags  as  variables  are  defined,  referenced,  and  undefined,  and 
noting  any  illegal  state  transitions.  Program  instrumentation 
requires  much  of  the  information  normally  available  in  a compiler; 
therefore  it  is  becoming  a feature  of  experimental  test  facilities 
that  program  instrumentation  be  performed  as  a compiler  option. 

More  extensive  instrumentation  of  the  source  program  is 
involved  in  execution  analysis  or  execution  histogram  systems. 

Such  systems  have  as  a goal  the  creation  of  a data  base  of  pro- 
gram execution  information  that  can  be  output  in  batch  fashion 
or  remain  available  for  interactive  query.  These  systems  facili- 
tate source  language  debugging,  can  provide  control  and  data 
flow  information,  environmental  information,  assertion  checking, 
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tracebacks,  etc.  The  information  can  aid  static  analysis  and 
dynamic  testing  (path  analysis  or  other) . There  are  drawbacks 
to  these  systems:  very  high  cost,  both  in  development  and  use, 
lack  of  generality  (machine  and  language  dependent  usually) , 
and  the  attendant  problems  of  handling  the  large  data  bases  that 
can  be  created.  Fairley  describes  an  Interactive  Semantic 
Modeling  System  (ISMS)  implemented  experimentally  for  application 
to  Algol  60  prgrams  (11) . The  Naval  Sea  Systems  Command  has 
successfully  used  a software  processor  AUDIT  to  aid  program 
verification  and  to  monitor  adherence  to  structured  programming 
standards  (71). 

Program  instrumentation  in  most  cases  involves  modification 
of  the  source  code,  and  generally  incurs  an  unacceptable  per- 
formance penalty  (as  does  the  evaluation  of  assertions) . There- 
fore it  is  common  to  remove  such  instrumentation  from  production 
programs,  and  to  repeat  dynamic  testing  with  the  optimal  set  of 
test  data  to  ensure  that  program  performance  remains  correct. 

There  are  two  simpler  automated  aids  to  dynamic  testing 
that  should  be  mentioned.  Generators  of  random  test  data  are 
not  uncommon;  although  random  data  do  not  generally  provide  a 
thorough  test,  they  are  easy  to  obtain.  While  automated  compu- 
tation of  the  expected  results  of  tests  is  not  feasible  (because 
such  computation  amounts  to  automation  of  the  function  of  the 
program  under  test  and  is  the  object  of  verification) , automated 
comparison  of  actual  results  with  the  expected  results  is  practical, 
and  useful  as  a labor-saving  aid.  The  expected  results  are 
typically  computed  by  hand  or  determined  from  historical  data, 
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or  bounds  defining  reasonable  results  axe  established  if  compu- 
tation is  overly  difficult. 


d. 


Limitations 


Limitations  to  the  effectiveness  of  dynamic  testing 
at  ensuring  the  correctness  of  software  were  evident  in  the  dis- 
cussion of  the  difficulty  of  determining  a reliable  measure  of 
test  thoroughness.  An  additional  drawback  to  any  form  of  dynamic 
testing  is  the  cost  both  in  time  and  resources. 

Testing  or  verification  techniques  include  several  indepen- 
dent or  even  contradictory  methods,  due  to  the  infancy  of  soft- 
ware engineering  and  program  testing  theory.  The  rationalization 
of  this  apparent  inconsistency  lies  in  the  realization  that, 
given  the  present  understanding  of  software,  nearly  every  soft- 
ware development  is  a unique  and  individual  design.  Cerification 
of  such  programs  requires  the  testing  team  to  be  familiar  with 
a variety  of  testing  methods  and  tools,  and  to  judiciously  apply 
those  which  seem  best  suited  to  the  task  at  hand. 


II.  NATURE  OF  THE  PROBLEM 


A.  A THEORY  OF  TESTING 

As  alluded  to  in  the  first  chapter,  a tentative  theoretical 
basis  for  the  testing  of  software  has  been  formulated  by  Good- 
enough  and  Gerhart  (17) . That  theory  is  capsulized  in  this 
section. 

1 . Types  of  Errors 

Testing  is  a process  of  collecting  and  analyzing  evidence 
relating  to  the  presence  of  errors.  To  reach  a meaningful  con- 
clusion as  to  the  presence  of  errors,  the  nature  of  errors  must 
be  clear.  On  a logical  basis,  errors  can  result  from  failure 
in  implementing  the  specification  (construction  errors) , failure 
of  the  specification  to  accurately  reflect  the  design,  failure 
of  the  design  to  adequately  solve  the  requirements  that  are  under- 
stood, or  failure  to  identify  the  real  requirements.  Each  of 
these  logic  errors  will  ultimately  appear  as  an  inappropriate 
effect  produced  by  the  implementation,  namely  as: 

a.  missing  control  flow  paths, 

b.  inappropriate  path  selection,  or 

c.  inappropriate  or  missing  action  on  a path. 

Recognizing  the  types  of  inappropriate  effects  that  may  be 

caused  by  errors,  the  problem  in  testing  is  to  select  test  cases 
that  can  show  that  these  errors  do  not  arise.  As  mentioned  ear- 
lier, a common  criterion  for  selecting  test  data  is  to  choose 
data  which  will  exercise  each  arc  or  branch  in  the  directed  graph 
representing  the  program  at  least  once.  Because  logic  errors. 


particularly  specification,  design,  and  requirements  errors , may 
be  manifested  by  missing  paths,  it  should  be  obvious  that  this 
criterion  alone  cannot  select  test  data  that  will  thoroughly 
test  a program. 

2 . Criteria  for  Test  Case  Selection 

Goodenough  and  Gerhart  defined  an  ideal  test  as  one  which 
succeeds  only  when  a program  contains  no  errors.  They  defined 
two  predicates  about  a criterion  C for  selecting  test  cases  that 
if  satisfied  are  sufficient  to  establish  that  any  complete  test 
is  an  ideal  test  (a  complete  test  is  one  using  the  criterion  C 
to  select  a set  of  test  data  T which  are  subsequently  used  to 
dynamically  test  the  program).  These  predicates,  RELIABLE (C) 
and  VALID(C) , are  defined  as  follows.  A criterion  is  reliable 
only  if  all  complete  tests  yield  the  same  (not  necessarily 
accurate)  result;  that  is,  if  one  complete  test  rs  successful 
(no  program  errors  are  revealed) , then  all  complete  tests  must 
be  successful,  and  if  one  complete  test  reveals  an  error,  all 
must  reveal  that  error.  Reliability  of  criteria  refers  to  con- 
sistency; using  a reliable  criterion,  a second  complete  test  is 
redundant  as  it  can  provide  no  new  information.  A criterion  is 
valid  only  if  for  every  error  that  can  exist  in  a program  there 
is  (at  least)  one  complete  test  that  can  show  the  presence  of 
the  error. 

The  concept  of  reliability  of  a criterion  for  selecting  test 
cases  is  not  to  be  confused  with  the  earlier  definition  of  soft- 
ware reliability  as  a measure  of  the  extent  to  which  programs 
satisfactorily  perform  their  intended  functions. 


31 


The  fundamental  theorem  of  testing  that  Goodenough  and  Gerhart 


have  suggested  is  simply  that  there  exist  some  criterion  C for 
selecting  test  data  and  some  subset  T of  a program's  input  domain 
D such  that  when  it  is  shown  that  a test  using  test  data  T is 
a complete  test  and  that  the  criterion  C is  both  reliable  and 
valid,  then  success  of  the  test  implies  that  the  program  is 
correct. 

Stated  formally,  the  theorem  is: 

(3TSD)  (3C)  [ (COMPLETE (T,C)aRELIABLE(C) 

/\  VALID(C)  A SUCCESSFUL (T)  ) =>  (Vd£D)OK(d)  ] , 

where  COMPLETE  (T,C)  is  a predicate  indicating  that  the  test  T 
is  complete  according  to  the  criterion  C,  and  OK(d)  is  a pre- 
dicate indicating  that  program  execution  with  the  element  d 
from  the  input  domain  D produces  the  results  required  by  the 
program  specification. 

The  theorem  is  not  profound;  its  proof  is  simple  and  is 
assured  by  the  convenient  definitions  of  reliable  and  valid 
criteria.  If  there  is  some  complete  test  capable  of  revealing 
any  error  (valid  criterion)  and  if  all  complete  tests  yield  the 
same  result  (reliable  criterion),  then  clearly  any  complete 
test  based  on  a valid  and  reliable  criterion  must  correctly 
demonstrate  the  presence  or  absence  of  errors. 

For  the  skeptic,  a proof  of  the  theorem  may  be  written  as 
follows : 

- As  to  the  existence  of  such  a T£D  and  criterion  C,  either 
the  program  is  correct  or  it  is  not.  If  it  is  correct,  then  a 
criterion  C such  that  a complete  test  T is  (d),  where  d is  any 
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element  of  D,  will  satisfy  the  theorem.  If  the  program  is  not 
correct,  there  is  some  element  d€.D  such  that  -tOK(d).  Then  a 
criterion  C such  that  T»{d}  is  a complete  test.  In  either  case, 
the  required  conditions  are  satisfied,  and  the  criterion  and 
test  set  exist  (the  challenge  for  the  program  tester  is  to  dis- 
cover them) . 

- As  to  the  theorem's  implication,  assume  the  truth  of  the 
hypotheses  and  assume  (3deD)  — |OK(d);  i.e.,  assume  the  theorem 
is  false. 

- Then  VALID (C)  =*  (5T«D) [COMPLETE (T,C) /\  -i  SUCCESSFUL  (T) ] . 

- Then  RELIABLE  (C)^"all  complete  tests  fail." 

- But  this  contradicts  an  hypothesis  of  the  theorem,  namely 
(3TSD) SUCCESSFUL (T) . 

- End  of  proof. 

Use  of  the  theorem  is  not  an  easy  matter.  A criterion  for 
selecting  test  data  must  be  chosen  and  that  criterion  must  be 
proven  reliable  and  valid.  Techniques  using  dynamic  testing  to 
"prove"  software  correctness  will  be  practical  only  if  the  proofs 
of  criterion  reliability  and  validity  are  simpler  to  construct 
and  at  least  as  convincing  as  proofs  of  program  correctness. 

The  experiments  reported  in  this  thesis  examined  some  aspects 
of  applying  the  above  theorem. 

B.  SATISFYING  THE  PREMISES  OF  THE  THEORY 

1.  Formal  Proofs  of  Correctness 

A degenerate  application  of  the  above  fundamental 
theorem  of  testing  is  selection  of  a criterion  C such  that  a 
complete  test  is  complete  only  if  T is  the  null  set;  in  this 
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case,  no  testing  is  done.  The  criterion  C is  clearly  reliable 
since  there  can  be  no  tests.  To  show  that  C is  valid  (any 
possible  program  error  will  be  revealed  by  at  least  one  comnlete 
test-),  it  must  be  shown  that  the  program  has  no  errors  at  all. 
Application  o*  the  theorem  with  such  a criterion  is  therefore 
equivalent  to  a proof  of  program  correctness.  Such  a proof 
was  constructed  for  the  sample  program  of  this  thesis  (Chapter 
IV,  Section  B) . 

2 . Symbolic  Execution 

Symbolic  execution  is  a technique  whereby  symbols  are 
used  as  input  values  rather  than  real  data  elements  and  the 
program  is  symbolically  executed  by  replacing  all  data  operations 
with  symbolic  operations.  Intermediate  results  then  are  compu- 
tational expressions  of  the  input  symbols  rather  than  data 
objects.  In  the  case  of  conditional  branching  in  the  program, 
logical  statements  on  the  input  symbols,  called  path  conditions, 
describe  the  conditions  under  which  a given  control  path  may  be 
traversed.  Program  correctness  is  shown  by  proving  that  at 
termination  the  constraints  of  path  conditions  imply  that  the 
computational  expressions  of  input  symbols  are  equivalent  to 
those  required  by  the  program  output  specification.  That  proof 
and  the  required  proof  of  similar  intermediate  theorems  con- 
stitute a general  theorem-proving  problem;  automated  theorem- 
proving capabilities  are  currently  quite  limited,  and  proving 
the  theorems  by  hand  is  quite  tedious.  This  drawback  restricts 
the  practical  use  of  formal  proofs  of  correctness  as  well.  A 
system  for  symbolic  program  execution  is  described  in  Ref.  8. 
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Symbolic  execution  is  related  to  the  theorem  of  testing  in 
that  the  criterion  C is  to  choose  input  symbols  satisfying  the 
program's  input  specification;  to  show  the  reliability  and 
validity  of  C,  it  must  be  shown  that  the  output  specification 
of  the  program  can  be  expressed  as  a computational  expression  of 
input  symbols  and  that  the  intermediate  expressions  are  valid 
over  the  entire  domain  of  values  for  input  symbols. 

The  technique  of  sumbolic  execution  was  not  directly  applied 
in  these  experiments;  however,  the  experiment  using  test  data 
execution  and  the  principle  of  distributed  correctness  (Chapter 
IV,  Section  C)  relied  on  some  of  the  ideas  of  symbolic  execution 

3.  Test  Data  Execution 

Clearly  one  ideal  test  is  execution  of  the  program  for 
every  member  of  the  program's  input  domain.  Since  most  input 
domains  are  infinite,  this  test  is  usually  impossible  and  nearly 
always  prohibitively  costly,  and  can  therefore  hardly  be  called 
ideal  in  any  practical  sense.  Goodenough  and  Gerhart  used  in 
Reference  17  a "condition  table  method"  to  select  test  data  for 
program  execution.  While  they  were  not  able  to  conclusively 
prove  the  reliability  or  validity  of  this  method  as  a selection 
criterion,  they  attempted  to  show  that  they  did  identify  equiva- 
lence classes  covering  the  input  domain  of  an  example  program 
and  choose  a representative  of  each  class  which  by  induction 
tested  each  member  of  that  equivalence  class.  The  condition 
table  method  was  incorporated  in  an  experiment  of  this  thesis 
in  conjunction  with  the  distributed  correctness  principle. 


Test  data  selection  techniques  such  as  path  analysis  and 
independent  sub-structure  analysis  are  also  attempts  to  identify 
equivalence  classes  in  the  input  domain,  while  again  only  in- 
formally trying  to  establish  criterion  reliability  and  validity. 
These  techniques  were  used  in  the  experiment  reported  in  Chapter 
IV,  Sections  D and  E;  in  each  case,  however,  it  was  not  possible 
to  determine  whether  the  equivalence  classes  identified  actually 
covered  the  input  domain  until  comparison  with  the  results  of 
other  experiments . 
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III.  EXPERIMENTAL  PROCEDURES 

An  example  program  was  selected  for  experimentation,  and 
several  verification  methods  were  applied  to  demonstrate  the 
correctness  of  the  example  program  The  hours  of  effort  required 
for  each  method  were  recorded  and  qualitative  assessments  were 
made  about  the  degree  of  difficulty  of  using  each  method.  The 
example  program  and  the  methods  employed  are  described  in  this 
chapter;  the  actual  results  and  a comparison  of  the  methods  is 
presented  in  the  next  chapter. 

A.  THE  PROGRAM  AND  INTUITIVE  TEST  DATA 

1 . Origin  and  Description 

Reference  20  is  a report  of  an  experiment  in  software 
error  occurrence  and  detection  conducted  at  the  Naval  Post- 
graduate School.  Four  programming  projects  were  undertaken  and 
data  were  recorded  on  the  man-hours  expended  in  each  development 
phase,  time  of  detection  and  occurrence  of  errors,  and  man-hours 
expended  correcting  errors.  Errors  were  classified  according 
to  the  development  phase  in  which  they  occurred  and  by  descriptive 
types,  and  were  analyzed  with  respect  to  development  phase, 
correction  time,  and  program  complexity. 

Project  number  one  of  Reference  20  was  chosen  as  a program 
for  experimental  verification.  The  subject  program  reads  and 
processes  a variable  length  string  of  text  characters,  recording 
all  occurrences  of  palindromes  (sub-strings  which  read  the  same 
forward  or  backward) , including  overlapping  palindromes  and 
omitting  palindromes  entirely  included  wit,h  another.  The  program 
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was  written  in  Algol-W  to  run  under  OS/MVT.  It  contains  141 
source  statements  and  consists  of  the  main  program  and  ten 
procedures,  five  of  which  are  significant  to  the  palindrome- 
finding algorithm;  the  remaining  five  are  called  to  print  the 
results.  The  original  program  development  required  5.0  man- 
hours in  the  design  phase,  7.0  in  the  coding  phase,  4.0  in 
debugging,  and  5.8  hours  in  the  original  testing  phase. 

2 . Program  Listing 

Figure  1 is  a listing  of  the  palindrome  program. 


toff  la 

conusant  Thla  program  finds  palindrome*  within  a character  etrlnff 
of  maximal  length  * 256. 

Minimum  string  length  is  2. 

All  Input  cards  will  ha  listed. 

The  program  will  produce  a list  of  only  those  palladroams 
which  are  not  entirely  Included  In  a larger  palindrome; 

comment  data  dec lara l !«ns t 

string! 1)  array  text! 1 :: 256) ; comment  contains  character 

string; 

s tr 1 ng! 89)  cardbuffer;  comment  l/o  buffer  for  cards; 

Integer  array  begin_of_pa 1 indrome . end_of— pa  1 ladrome! 1 * : 256) ; 

Integer  cardllmit,  length_o f_text , buf ferpos 1 1 Ion.  card-counter , 
pa  1 1 nd r o me  —counter; 

Integer  lx.  jx;  comamnt  Index  variables; 

comment  Initialization; 
procedure  initialize; 

comment  Initialize  all  variables,  read  length— of— text . write  textl; 

begin 

text  1 ; 

jx!  * 1 ; 

pa  1 Indrome .counter : * 1 ; 
card  1 1ml t : 3 86; 

Int f le Ids ize • *5 ; 
read! length_o f— text ) ; 

if  ! ! length— of— text  < 2)  or  t length_o f -text  > 256))  then 
begin 

write! ’Illegal  Input:*.  v 

* length  of  Input  string  is:  length— o f— text) ; 

assert! false) ; 
end  i 

cardbuffer:*’  ’; 
end  initialize; 

comment  utilities; 

procedure  b lank— 1 lnes! integer  value  n) ; 

comment  write  n blank  lines; 

begin 

Integer  1;  comment  local  counter; 

assert! n>0) ; comment  safoty  check; 

for  l:*l  step  1 until  n do  write!’  ■) ; 
end  blank— lines; 

procedure  textl; 
begin 

write! 'Find  all  palindromes  within  the  following  string:"); 
b lank_l lnes! 2) ; 

write!  ’Card  Text"); 

write!  * If  umber  ")  ; 
b lank— 1 lnes! 1 ) : 
end  textl; 
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procedure  text 2 i 
begin 

b lank— 1 lne»( 2) i 

wr i te( "The  following  palindromes  bare  been  detected: ")  ; 
b lank-1 inea< 1) t 

wr 1 te( "Pa  1 Indrone  Begin  End"): 

wrl  te!  'Number  Card  Character  Card  Character") t 

write!  ’ Number  Poe  It  Ion  Number  Position”); 

wr  1 te  ( « 

wrl teon!  * ”1 1 

end  text2; 

procedure  text3; 
begin 

write! "N o palindromes  fonnd.  End  of  run."); 
end  text3; 

procedure  read— and— wr 1 te— Input— cards ; 

comment  read  Input  cards  according  to  glean  length— of— text ; 
begin 

integer  number— of— Input— cards ; 

number— of —Input— cards : - ( length— o f— text  - 1)  d lv  card  1 1ml t + 1; 
ist>lf  comment  reset  text  lndexi 

for  card— counter : s 1 step  1 until  number-of— Input— cards  do 
begin 

wr i te! card— counter) ; 
wr 1 teon! * ") ; 
readcard! cardbuf for ) t 
wr 1 teon( cardbuf fer) t 

buf ferpoe 1 t ion: *0:  comment  reset  index; 

while  (( lx< * length— of— text)  and  ( buf ferpos i t ion< card  1 imi t ) ) do 
begin 

text! lx) :*cardbuffer!bufferposlt lonl 1) ; 
lx:* lx+1; 

buf  ferpos 1 1 Ion: * buf ferpos 1 1 lon+ 1 ; 

end;  coomient  done  for  all  characters  on  a card; 

end;  comment  done  for  all  cards; 

end  read— and— wr 1 te— Input— cards ; 

procedure  wr  i te— a 1 1—  pa  1 1 nd routes  ; 

comment  list  all  palindromes  being  found; 

begin 

integer  i.j;  comment  local  counters; 

text2; 

for  i:*l  step  1 until  jx— 1 do 
begin 

if  end— of— pe 1 indrome! 1)  0 then 

begin 

wr 1 te!  pa  1 indrome -coon  ter) ; 
writeon! " *) ; 

wr 1 teon! (( begin— of_pa 1 Indrome! 1 )-l)  d Iv  card  1 1ml t)  + 1); 
wr  1 teon!  " " ) ; 

If  ! begin— o f_ pa  1 lndrome! 1)  rem  cardlimlt  * 0)  then 
wr  1 teon! card  1 1ml t ) 

e lse 

wr  1 teon! ( begin— o f_pa 1 lndrome!  i ) rem  cardlimlt)); 
wr  1 teon! " ") ; 

wr  1 toon! ( ( end— o f — pa llndrome!l)-l)  d i ▼ cardlimlt)  + 1); 
wr 1 toon!  " ") ; 
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if  (end— of-palindrone<  i)  raa  cardltmit  *•)  than 
wr i taoa( card  1 1ml t) 

a laa 

wr  i teon( ( end— of— pa 1 lndrome(  i ) rea  cardllalt)); 
wr  1 te(  • ">t 

for  j:ab«(ia.of.pilladroai( 1)  atap  1 

until  end-of-pal indronet 1)  do  wr iteonf taxtC j) ) ; 

wr  i ta(  * « 

writeon(  * " * * 

blank— 1 lnea( 1) ; 

pa  1 1 ndrome -counter : 3 pa 1 1 ndrome— count er+ 1 1 
end;  comment  and  1ft 

andt  conant  dona  for  all  palindromes: 

and  write— al 1— pal indroaes; 

■ant  subroutines; 
procedure  pa  1 Indrone— check; 

comaent  find  all  palindromes  within  girsii  text  strlaft 
basin 

comaent  acan  text  from  left  to  rlsht; 
for  lx: *2  atap  1 until  lensth-of— text  do 
basin 

if  text(lx-l)  3 text( ix)  than  cont inue— checkins* < ix-1) , lx) t 
if  lx  ~3  2 than 

If  text( ix-2) * text( ix)  than  cont inue— checkins! < ix-2) , ix) t 

end  i 

end  pal indrome-chackt 

procadura  cont inue— checkins  ( inteser  value  first,  last); 
comment  Given  first  and  last  aa  pointers  to  a palindrome 

of  size  2 or  3,  this  procedure  checks  whether  or  not  this 
palindrome  ia  included  in  a larger  pal  indrome t 

basin 

losical  palindrome; 
pa  1 i ndrona : * t rue ; 

while  ( ( f irs t>  1)  and  ( last< lensth-of_text)  and  ( pa  1 Indrone3 true) ) do 
besin 

if  text< first-1)  3 text! last+1)  then 
basin 

consent  larger  palindrome  found; 
f irs  t : 3f irs  t- 1 ; 
las  t : 3 lss  t+ 1 ; 
end 

a lse 

basin 

pal  indrome: 3 fa lse;  comment  !ars«et  palindrome  found; 

end ; 

end  i 

record— pa  1 Indrome! first, last) ; 
end  cont inne-checklns: 
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procedure  record-pa  1 indrone  (Integer  mine  first, laet); 
connent  Record  only  an*  length  pal  Indrones.  Flag  prevlonaly 

recorded  pallndrones  If  they  are  Included  In  the  pal Indrone 
specified  by  first  and  last. 

jx  was  Initialized  to  1.  After  conpletlon  jz  points  to  the 
next  entry  In  begin— of— pa  1 Indrone  and  end— of— pa  1 Indrone t 

begin 

Integer  it  coaaent  local  counter; 

logical  eatryt 
entry; » trues 

for  U«1  step  1 until  jx-l  do 
begin 

if  ( ( f Ira t>«begin-of-pal Indrone  ( 1) ) 

and  ( last< *end_of_pal Indrone!  l) ) ) then 
begin 

coMit  Pa  1 indrone  is  entirely  Included  In  a previously 
recorded  pal indrone.  llo  entry  required t 
entry> » fa lse t 
end 

e lse 

begin 

if  ( ( begin_of— pal lndrone< i)  >*  first) 

and  < end_o f _pa 1 Indrone < I)  <■  last))  then 
begin 

end— o f — pa  1 indrone! l) : *•) 
consent  flag  ana  liar  pal  Indrone  t 
end  t 

end  t 

end;  constat  All  previously  recorded  pal  Indrones 

coaqtared  with  last  input; 

If  entry  * true  then 
begin 

conent  larger  than  all  previous  or  overlapping  or  disjoint; 

begin— of— pa 1 indrone(  jx) :*f Irat; 

end-of-pal lndrone<  jx) : * lasts 

jx:*jx+l; 

end  t 

end  record— pa  1 Indrone t 


•at  an  in; 


Ini t la  1 lze  t 

read and— wri te— input— cards; 

pa  1 Indrone -check; 

If  J x* 1 then  tezt3 

else  wr I te— a 1 1— pa  1 indrones ; 

end . 
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3.  Program  Graphs 


,1 


Figure  2 presents  the  control  flow  directed  graph  repre- 
sentations of  the  significant  procedures  of  the  example  program. 
The  graphs,  originally  presented  in  Reference  20,  are  annotated 
with  key-words  indicating  the  structured  programming  constructs 
comprising  the  decision  nodes,  lower-case  letters  which  label 
the  arcs,  upper-case  letters  representing  the  counters  placed  on 
the  individual  decision-to-decision  paths  for  path  analysis,  and 
with  complexity  measures  of  the  procedures.  The  complexity 
measures  shown  are  defined  as  follows: 

a.  The  number  of  statements  is  a count  of  the  source 
code  statements  in  the  procedure. 

b.  The  number  of  nodes  is  a count  of  the  nodes  in  the 
control  flow  graph.  Nodes  are  points  of  starting,  stopping, 
branching,  or  merging  of  control  flow;  i.e.,  decision  points. 

c.  The  number  of  arcs  is  a count  of  the  arcs  in  the 
graph.  Arcs  are  concatenations  of  zero  or  more  program  state- 
ments with  no  decisions  except  at  the  nodes. 

d.  The  cyclomatic  number  of  a strongly  connected  graph 
is  equal  to  the  maximum  number  of  linearly  independent  circuits 
(27) . A program  control  flow  graph  with  one  entry  and  one  exit 
such  that  each  node  can  be  reached  from  the  entry  and  such  that 
the  exit  can  be  reached  from  every  node  can  be  considered  as  a 
strongly  connected  graph  with  an  imaginary  arc  from  the  exit 
node  back  to  the  entry  node.  For  such  a control  flow  graph  the 
cyclomatic  number  can  be  variously  interpreted  as  the  maximum 
number  of  independent  paths , one  more  than  the  number  of  predicate 
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nodes  (nodes  with  more  than  one  path  leaving) , the  number  of 
regions  in  the  graph  (plane  graph  with  no  arcs  crossing),  or 
the  number  of  arcs  minus  the  number  of  nodes  plus  two  (27). 

The  experimental  method  described  in  Section  E of  this  chapter 
makes  use  of  the  cyclomatic  number. 
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Procedure : 

INITIALIZE 

Number  of  statements 
Number  of  nodes: 
Number  of  arcs: 
Cyclomatic  number: 


FIGURE  2 
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Procedure : 

CONTINUE^CHECKING 
Number  of  statements 
Number  of  nodes: 
Number  of  arcs : 
Cyclomatic  number: 


while 
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Procedure : 

RECORD^PALINDROME 
Number  of  statements : 
Number  of  nodes: 
Number  of  arcs: 
Cyclomat ic  number: 


21 

10 

13 

5 
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Page  5 of  6 
PROGRAM  GRAPHS 


49 


4.  Error  Data 


Forty-four  errors  were  detected  during  original  program 
development.  Error  descriptions  by  type  are  recorded  in  Reference 
20.  Table  I presents  the  errors  (using  Hoffman's  original  error 
numbering)  which  could  be  directly  related  to  a particular  pro- 
gram fragment. 


TABLE  I 


SELECTED  ERRORS 


Error 

Number  Procedure  Description 


1 read*-  and*-wr  ite... 

3 initialize 

4 initialize 

35  palindrome*-check 

36  palindrome*-check 

37  initialize 

42  initialize 


Need  for  256-character  variable 
"text"  in  addition  to  an  80- 
character  buffer  noted. 

Syntax  error. 

Syntax  error. 

Error  in  limits  to  counter  of 
for  statement. 

Missing  "if  ix->=2"  resulted  in 
indexing  error  at  run. 

"jx"  not  initialized;  resulted 
in  indexing  error. 

"jx"  initialized  to  0 vice  1. 


5 . Intuitive  Test  Cases 

After  a first  examination  of  the  example  program  and 
before  commencing  any  of  the  verification  experiments,  a set  of 
test  cases  was  selected  by  intuition  which  appeared  to  test  the 
program's  handling  of  all  conditions  significant  to  proper 
program  operation.  Those  test  cases  are  listed  in  Table  II. 

The  intuitive  test  cases  were  used  for  conducting  additional 

i 

dynamic  testing  after  completion  of  the  experiments  using  the 
methods  described  in  the  remainder  of  this  chapter. 
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TABLE  II 


Test 

Number 


~ --INTUITIVE  TEST  CASES 


String 

Length 


StTing  or 

String  Description 


1 

2 

3 

4 

5 


6 

7 

8 


2 

3 

1 

2S7 

256 


15 

100 

256 


"xx"  - length  2 palindrome 
"xyz"  - length  3 palindrome 
Invalid  string  length 
Invalid  string  length 

A maximum  length  string  containing  palin- 
dromes of  length  10,  9,  6,  and  12,  of 
which  the  first  included  length  3 palin- 
dromes at  both  ends , the  second  and  third 
overlapped,  and  the  fourth  was  written 
across  an  input  card  boundary. 

String  with  no  palindromes 
Entire  string  one  palindrome 
One  maximum  length  palindrome 


B.  PROOF  OF  CORRECTNESS 

A method  of  formal  proof  of  correctness  was  used  to  verify 
the  logical  correctness  of  the  algorithm  of  the  example  program. 
The  method  required  the  assumption  that  the  environment  in  which 
the  program  operates  is  also  logically  correct,  most  particularly 
that  the  compiler  and  operating  system  ensure  performance  -of  the 
expected  semantic  actions  for  the  program  statements. 

References  9,13,19,25  and  26  were  consulted  to  develop  the 
methodology  for  constructing  the  proof.  The  work  of  Floyd  (13) 
is  considered  the  basis  for  mathematical  program  proofs;  the 
paper  by  Manna  and  Waldinger  (26)  was  particularly  helpful  in  an 
operational  sense,  and  Hoare's  paper  (19)  was  applicable  to  the 
treatment  of  procedure  calls. 

The  first  step  in  constructing  the  proof  was  to  formalize 
the  required  result  of  the  program  in  a logical  statement  called 
the  output  assertion,  and  to  describe  the  restrictions  on  input 


data  as  an  input  assertion.  Translating  the  rather  loosely 
defined  purpose  of  finding  palindromes  to  an  output  assertion 
required  significant  analysis  of  the  requirements. 

The  proof  itself  was  constructed  using  the  method  of  in- 
variant assertions  to  show  partial  correctness;  i.e.,  that  when  the 
input  data  satisfied  the  input  assertion,  the  output  assertion 
was  satisfied  if  the  program  terminated.  Termination  of  the 
program  was  proven  separately  by  finding  for  each  loop  a set 
and  an  ordering  relation  on  that  set  such  that  the  set  can  have 
no  infinite  decreasing  sequences  (well-founded  ordering) , and 
defining  a termination  expression  which  is  a member  of  that 
set  and  which  is  decreased  each  time  control  passes  through  the 
loop.  The  proofs  of  partial  correctness  and  termination  together 
establish  the  "total  correctness”  (26)  of  the  program. 

The  method  of  invariant  assertion  involved  inserting  appro- 
priate intermediate  assertions  (also  called  Floyd  assertions)  at 
selected  labels  in  the  program  such  that  they  defined  a condition 
which  would  be  logically  true  each  time  control  passed  through 
that  label  (hence  the  name  invariant) . At  least  one  intermediate 
assertion  was  inserted  on  every  loop.  Corresponding  to  each 
path  between  assertions  a verification  condition  was  written.  A 
verification  condition  is  a theorem  of  the  form  < assertion  1> 
and  < semantic  meaning  of  program  statements  on  path  > implies 
< assertion  2 > . Proving  all  verification  conditions  completed 
the  proof  of  partial  correctness. 

The  construction  of  appropriate  verification  conditions  was 
aided  by  using  the  invariant  deductive  system  described  in 
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Reference  26.  The  notation  (P)  F (Q),  where  P and  Q are  logical 
statements  (assertions)  and  F is  a program  fragment,  is  used  to 
mean  that  if  P holds  before  executing  F and  if  F terminates, 
then  Q holds  after  executing  F.  Thus  the  proof  of  program  correct- 
ness is  a proof  of  the  invariant  statement: 

Unput  assertion ) program  (output  assertion). 

Rules  of  inference  were  supplied  in  Reference  26  to  provide  sub- 
goals for  proving  certain  invariant  statements;  in  particular 
there  is  one  rule  of  inference  for  each  statement  type  in  the 
programming  language.  For  instance,  the  rule  for  conditional 
statement  "if  R then  F else  G"  is  written  as: 

(P  and  R>  F (Q),  (P  and  -iR>  G (Q) 

(P ) if  R then  F else  G (Q ) 

The  notation  signifies  that  proof  of  the  two  invariant  statements 
in  the  nominator  of  the  "fraction"  is  sufficient  to  infer  the 
invariant  statement  in  the  denominator. 

The  reference  provided  rules  of  inference  for  assignment 
statements,  conditional  statements,  while  statements,  and  for 
the  concatenation  of  statements.  Additional  rules  were  formu- 
lated for  iterative  for  statements  and  procedure  calls.  The 
rules  are  introduced  as  required  in  the  presentation  of  the 
proof  (Appendix  A) . 

C.  DISTRIBUTED  CORRECTNESS 

Test  cases  for  dynamic  testing  were  selected  using  a criterion 
based  on  the  condition  table  method  of  Goodenough  and  Gerhart 
(17)  and  the  principle  of  distributed  correctness  described  by 
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Geller  (14) . The  criterion  was  not  proven  reliable  and  valid, 
but  an  effort  was  made  to  show  that  the  data  selected  were 
representative  of  equivalence  classes  covering  the  input  domain 
of  the  program  such  that  correct  operation  for  all  data  in  the 
domain  could  be  induced  from  correct  operation  for  the  test  data. 

4 

As  in  the  proof  of  correctness,  input  and  output  assertions 
were  stated.  At  selected  labels  in  the  program  (fewer  than  in 
the  correctness  proof) , "synthesized  assertions"  (14)  were  in- 
serted,  similar  to  Floyd  assertions  but  more  general.  The  syn- 
thesized assertions  expressed  invariant  conditions  of  the  program. 

A condition  table  was  constructed  (if  necessary)  to  analyze  all 
conditions  affecting  program  operation  from  the  previous  asser- 
tion to  the  one  under  consideration.  Test  data  were  selected 
for  each  class  identified  in  the  table  (similar  to  the  decision 
rules  of  a limited-entry  decision  table) , and  a "test  data 
assertion"  was  stated,  namely  that  execution  of  the  program 
fragment  with  the  test  data  would  satisfy  the  synthesized 
assertion.  The  test  data  assertion  was  verified  by  dynamic 
testing.  At  the  same  label,  a generalization  assertion  was  made 
attempting  to  state  the  conditions  for  correct  operation  of  the 
program  fragment,  and  where  possible  the  synthesized  assertion 
was  proven  from  the  test  data  and  generalization  assertions.  In 
several  cases,  however,  a basis  for  verifying  the  generalization 
assertion  could  not  be  found  and  hence  the  verification  method 
could  not  be  claimed  to  have  proved  program  correctness  through 
testing.  Certainly,  however,  an  intuitive  feeling  of  "high" 
reliability  and  validity  of  the  test  case  selection  criterion 
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was  established. 

The  principle  of  distributed  correctness  was  called  upon  to 
infer  program  correctness  from  the  correct  operation  of  the 
distributed  program  fragments  verified  by  the  synthesized 
assertions. 

D.  PATH  ANALYSIS 

1 . Basic  Technique 

Path  analysis  techniques  are  described  in  References  21, 
22,  23,  31  and  32.  For  the  example  program,  test  data  were 
selected  to  force  program  traversal  of  each  arc  of  the  program 
control  flow  graph.  Execution  of  the  arcs  labeled  with  upper- 
case letters  on  the  graphs  of  Figure  2 is  sufficient  to  ensure 
traversal  of  all  arcs.  Data  were  selected  to  satisfy  path  pre- 
dicates for  each  such  arc,  predicates  which  describe  constraints 
on  the  inputs  to  ensure  execution  of  the  arc.  The  program  was 
instrumented  with  a counter  on  each  labeled  arc  to  count  the 
number  of  arc  traversals,  thus  ensuring  after  testing  that  no 
arcs  had  been  missed. 

More  stringent  criteria  could  have  been  applied,  but  execution 
of  all  possible  control  paths  was  not  possible  since  the  program 
has  an  infinite  number  of  paths. 

2 . Extended  Technique 

The  method  of  selecting  test  data  as  described  above 
was  repeated  with  the  additional  criterion  that  each  conditional 
branching  statement  with  more  than  one  predicate  be  executed 
with  each  possible  combination  of  truth  values  of  the  predicates, 
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thus  expanding  the  class  of  errors  that  might  be  detected  by 
the  tests.  Additional  path  predicates  were  considered  and  a 
larger  set  of  test  data  was  selected. 

E.  INDEPENDENT  SUB -STRUCTURES . 

A method  for  selecting  test  cases  which  is  similar  to  path 
analysis  has  been  suggested  in  References  27  and  33.  As  applied 
herein,  the  technique  was  to  decompose  the  control  flow  graph 
of  each  procedure  of  a program  into  independent  circuits  corre- 
sponding to  language  constructs  and  to  use  these  sub -structures 
as  an  aid  in  identifying  control  flow  paths  for  testing.  The 
cyclomatic  number  of  a single-entry  single-exit  procedure  is 
the  maximum  number  of  such  sub - structures ; these  independent 
circuits  can  be  identified  by  inspection  for  simple  graphs  or 
more  generally  as  follows: 

A spanning  tree  (33)  is  a connected  sub-graph  consisting  of 
all  nodes  of  a procedure's  graph  but  containing  no  circuits.  Its 
arcs  are  called  branches.  There  is  one  independent  circuit 
corresponding  to  each  arc  of  the  parent  graph  not  included  in 
the  spanning  tree;  these  arcs,  including  an  imaginary  arc  from 
the  exit  node  back  to  the  entry  node,  are  called  chords.  As 
each  chord  is  added  to  the  spanning  tree,  the  corresponding  in- 
dependent circuit  can  be  identified. 

A matrix  representation  of  the  circuits  was  useful  in  gener- 
ating control  paths  for  dynamic  testing  from  the  sub -s true tures . 
A fundamental  circuit  matrix  (33)  was  constructed  with  rows 
corresponding  to  arcs  (chords  and  branches) ; its  entries  were 
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0 for  arcs  not  contained  in  a circuit,  1 for  arcs  oriented  in 
the  direction  of  an  assumed  circuit  flow,  and  -1  for  arcs 
oriented  against  the  assumed  flow.  Chords  were  listed  on  the 
left  of  each  row,  forming  a unit  matrix  because  there  is  a one- 
to-one  correspondence  between  chords  and  circuits. 

The  usefulness  of  the  fundamental  circuit  matrix  was  that 
linear  combinations  of  circuits  (the  rows)  having  at  least  one 
arc  in  common  generated  control  paths  useful  for  testing.  Selec- 
tion of  paths  in  this  manner  satisfied  a criterion  more  stringent 
than  traversal  of  each  arc  at  least  once,  while  considerably  less 
stringent  than  traversal  of  all  possible  paths. 

In  Section  E of  Chapter  IV,  the  results  of  the  application 
of  this  technique  are  discussed.  Following  the  generation  of 
the  paths  to  be  tested,  test  data  were  selected  to  satisfy  the 
path  predicates  and  dynamic  testing  was  conducted. 
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IV.  PRESENTATION  OF  RESULTS 


A.  STATIC  ANALYSIS 

Prior  to  the  commencement  of  the  experimental  methods,  1.0 
man-hours  of  effort  were  expended  in  static  analysis  of  the 
example  program.  Code  was  read  to  check  syntax  and  reachability 
of  program  fragments,  and  control  flow  graphs  were  examined  to 
check  for  adherence  to  structured  programming  constructs  and 
to  learn  the  general  flow  of  the  program.  No  exceptions  were 
noted  in  these  areas. 

All  global  and  local  variables  were  examined  to  ensure 
proper  declarations  and  to  check  the  transitions  among  the  states 
of  being  undefined,  defined  and  not  referenced,  defined  and 
referenced,  and  an  anomalous  state  (23).  No  illegal  state 
transitions  were  found;  however,  two  instances  of  questionable 
programming  practice  were  noted.  First,  the  string  array  variable 
"cardbuffer"  is  initialized  to  contain  80  blank  characters  in 
the  procedure  "initialize"  (state  = defined  and  not  referenced) . 

In  a data  flow  sense,  the  next  action  performed  on  that  variable 
is  to  re-define  it  in  the  procedure  "read-^and^write^input^cards ," 
thus  transitioning  to  the  anomalous  state.  Since  the  variable 
is  re-defined  before  being  referenced,  the  initializing  of 
"cardbuffer"  in  the  "initialize"  procedure  is  superfluous. 

Second,  all  iterative  counters  in  for  statements  in  the  example 
program  are  explicitly  declared.  Because  the  Algol-W  compiler 
implicitly  declares  such  counters,  the  effect  in  the  example 
program  is  to  explicitly  declare  several  variables  that  are 
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subsequently  not  defined  or  referenced.  Although  this  is  a 
shortcoming  in  style,  the  superfluous  declarations  cause  no 
ill  effects  other  than  to  waste  a small  amount  of  storage. 

The  verifications  performed  during  static  analysis  were 
required  to  ensure  satisfaction  of  several  assumptions  for  the 
experiments  in  correctness  demonstration,  particularly  that  the 
program  has  no  significant  data  flow  anomalies  and  that  the 
program  is  well  structured  and  procedures  do  not  contain 
statements  leading  to  unexpected  side  effects.  The  two  in- 
stances of  style  noted  above  were  not  corrected  prior  to  ex- 
perimentation. 

B.  PROOF  OF  CORRECTNESS 

The  detailed  proof  of  correctness  for  the  example  program 
is  presented  in  Appendix  A.  The  first  step  in  constructing 
the  proof  was  to  formalize  the  output  specification  of 'the 
program,  a task  requiring  0.8  man-hours  of  effort.  It  was 
desired  to  prove  that  at  program  termination  the  arrays  "begins 
of^-palindrome"  and  "end«-of«-pal indrome"  would  contain,  correspon- 
ding to  indices  starting  from  1,  integers  representing  the 
’beginning  and  ending  characters  in  the  string  "text"  for  all 
palindromes  in  the  string,  subject  to  the  constraint  that 
palindromes  fully  contained  within  a larger  palindrome  would 
not  be  recorded.  A palindrome  initially  recorded  in  the  arrays 
and  subsequently  found  to  be  included  in  a larger  one  would  be 
"deleted"  by  setting  the  "end«-of«-pal indrome"  entry  to  zero. 
Overlapping  palindromes  would  be  recorded. 





The  formal  statements  made  for  the  specification  are  ("£" 
is  an  abbreviation  for  " 1 eng  th+of-*- text" ; "bop"  and  "eop"  are 


abbreviations  for  the  beginning  and  ending  entry  arrays;  "jx" 
is  a counter  which  is  equal  to  one  more  than  the  number  of  entries 
made  in  those  arrays) : 

Q:  Vx [(2<’x<=£,  a text  (x-1) -text  (x))=5> 

3y  (y<  jx  a K-bop(y)  <»x-l  a x<»eop(y)<’t)  ] 

R:  V x [ ( 3<*x<*£  a text  (x-2) ’text  (x) ) -»» 

3y(y<jx  a l<=bop(y) <’x-Z  a x<*eop(y) <»t) ] 

S:  ^y[(0<y<jx  a bop(y)>l  a 0<eop(y)<4)  — *> 

(text (bop (y) -1) ’text (eop (y) +1) ) ] 

T:  Vy[  (0<y<jx  a (eop(y)-O) ) 

[string (bop (y) ,eop(y) )’ok  a bop(y)>»l  a eop(y)<=£ 
aVz(  (0<z<jx  A (z»y) ) ==> 

( — » (bop(z)’bop(y)) 

a (bop(z)  <bop(y)  eop(z)<eop(y)))  )] 

The  assertions  Q and  R require,  respectively,  that  all 
palindromes  of  length  2 and  length  3 are  included  within  some 
entry  in  the  arrays  "bop"  and  "eop."  Due  to  the  symmetry  of 
palindromes,  all  must  contrain  a palindrome  of  length  2 or  3 at 
the  center;  therefore,  when  conditions  Q and  R are  satisfied, 
all  palindromes  have  at  least  been  detected  by  the  workings  of 
the  algorithm,  even  if  their  total  extent  has  not  been  recog- 
nized. Condition  S requires  that  any  valid  entry  in  the  arrays 
"bop"  and  "eop"  represents  as  long  a palindrome  as  can  be 
recognized  starting  from  the  length  2 or  3 palindrome  at  the 
center;  symmetry  is  again  relied  upon.  Finally,  condition  T 
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requires  that  all  strings  represented  by  valid  entries  (those 
with  non-zero  "eop"  entry)  are  in  fact  palindromes  (the  notation 
"string(l,2)*ok"  is  used  to  indicate  that  the  sub-string  starting 
at  position  1 in  "text"  and  ending  at  position  2 is  a palindrome), 
and  that  no  entry  in  the  arrays  "bop”  and  "eop"  is  included 
with  another  entry. 

Together  the  four  assertions  provided  a formal  statement 
that  could  be  proved  from  the  semantics  of  program  statements 
and  the  assumption  that  the  input  constraints  (see  Appendix  A) 
have  been  satisfied. 

Given  the  output  specification  to  be  proven,  five  procedures 
were  determined  during  static  analysis  to  have  no  bearing  on  the 
program's  performance  of  the  desired  process.  Procedures  "textl," 
"text2,"  and  "text3,"  merely  print  output  labels;  "blank-*- lines" 
inserts  blank  lines  in  the  output.  Procedure  "write-*-all-*-palin- 
dromes,"  while  complex,  serves  only  to  print  the  strings  corre- 
sponding to  the  entries  in  the  previously  mentioned  arrays.  No 
correctness  proof  other  than  for  termination  was  supplied  for 
these  procedures. 

For  the  remaining  significant  procedures,  Table  III  presents 
the  man-hours  of  effort  expended  in  constructing  their  proofs. 

As  is  discussed  in  Chapter  V,  there  was  a relationship  between 
procedure  complexity  and  the  time  to  construct  a proof  for  the 
procedure.  The  time  required  to  prove  procedure  "read-*-and-*-write-<- 
input-*-cards ,"  the  first  somewhat  complex  procedure  proved,  was 
distorted  by  the  presence  of  a significant  learning  curve. 
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TABLE  III 

TIMES  TO  CONSTRUCT  PROOFS 


Task  Accomplished  or 


Procedure  Proved 

Man-Hours 

Formalize  output  specification 

0.8 

"initialize" 

0.8 

Show  termination  of  5 utilities 

0.6 

" r e a d«-  a n d«- wr  i t e^ «-  i np  u t <-  c a r d s " 

4.2 

"pal  indrome-*-  check" 

1.6 

"continue-*-checking" 

1.8 

"record«-pal  indrome" 

3 . S 

"main" 

0.2 

Total 

13'.  5 

C.  DISTRIBUTED  CORRECTNESS 

The  detailed  demonstration  of  correctness  of  the  example 
program  using  the  condition  table  method  and  the  principle  of 
distributed  correctness  (described  in  Chapter  III)  is  presented 
in  Appendix  B.  As  in  the  formal  proof  of  correctness,  this 
method  required  formalization  of  the  output  specification  as 
a first  step;  the  same  output  assertions  were  established  as 
in  the  formal  proof.  The  six  significant  procedures  were  tested 
by  choosing  synthetic  assertions,  test  data  assertions,  and 
generalization  assertions,  and  then  executing  test  data  to 
verify  the  assertions.  Table  IV  presents  the  man-hours  of 
effort  expended  in  demonstrating  correctness  by  this  method. 
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TABLE  IV 


TIMES  TO  DEMONSTRATE  CORRECTNESS 


Task  Accomplished  or 

Procedure  Shown 

Man-Hours 

Formalize  output  specification 

0.8 

"initialize” 

0.2 

"read«-and-*-write-‘-input-*-cards 

0.7 

"pal indr ome+check" 

0.9 

"continue-*- checking" 

1.3 

"record+palindrome" 

"main" 

3.2 

0.4 

Total 

7.5 

The  test  data  elements  used  to  verify  the  test  data  asser- 
tions in  the  correctness  demonstration  are  consolidated  in 
Table  V into  one  comprehensive  set  of  test  cases;  the  palindromes 
which  should  be  recorded  for  the  given  texts  are  indicated  by 
underscoring.  The  degree  to  which  these  test  cases  satisfied 
the  requirements  for  an  ideal  test  is  discussed  in  a later  section. 


TABLE  V 


TEST  CASES 

IDENTIFIED  BY 

CONDITION 

TABLE  METHOD 

Test 

Length 

Test 

Length 

Number 

of  text 

Text 

Number 

of  text 

Text 

1 

2 

ab 

13 

4 

aabc 

2 

2 

aa 

14 

4 

aFb  a 

• 

3 • 

80 

Note  1 

15 

4 

abbc 

* 

4 

81 

Note  1 

16 

5 

aFFad 

5 

160 

Note  1 

17 

5 

abbcd 

6 

240 

Note  1 

18 

5 

aFccb 

7 

256 

Note  1 

19 

5 

abccd 

8 

3 

aba 

20 

6 

abccba 

9 

3 

aab 

21 

6 

abccbd 

10 

3 

aFb 

22 

6 

abccde 

11 

4 

abcc 

23 

9 

b a aab a aab 

12 

4 

aaaa 

Note  1 - any  text  which  includes  overlapping  palindromes 
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For  purposes  of  comparison  with  later  sets  of  test  cases, 
it  is  noted  that  execution  of  the  above  tests  required  0.88 


! 


seconds  of  CPU  time. 

D.  PATH  ANALYSIS 

1.  Basic  Technique 

Static  analysis  of  the  program  identified  21  individual 
decision- to-decision  paths  in  the  program  control  flow  graph. 

The  program  was  instrumented  with  integer  counters  placed  in 
added  assignment  statements  to  record  the  number  of  traversals 
of  each  of  these  arcs  (which  are  identified  by  upper-case  letters 
in  Figure  2,  Chapter  III).  The  analysis -and  instrumentation 
required  0.8  man-hours  of  effort. 

Path  predicates  were  established  and  test  cases  selected  to 
force  traversal  of  each  arc  at  least  once  (0.3  man-hours  required).' 
For  the  example  program  the  path  predicates  were  quite  simple 
to  satisfy.  Finally,  the  test  data  (shown  in  Table  VI)  were 
used  in  dynamic  testing  of  the  program  (0.2  man-hours).  Table 
VII  lists  the  individual  arcs  and  the  number  of  traversals  of 
each  which  were  recorded.  No  program  errors  were  detected.  Each 
arc  was  traversed  at  least  once,  and  thus  the  selected  data 
provided  at  least  a "minimally  thorough"  test  of  the  program 
(22) . The  total  effort  involved  in  the  application  of  this 
method  was  1.3  man-hours.  The  tests  required  0.05  seconds  of 
CPU  time. 
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TABLE  VI 

TEST  CASES  IDENTIFIED 


BY  PATH  ANALYSIS 


Test 

Number 


Length 
of  text 


Text 


xy 

baaaaca 


TABLE  VII 


ARC  TRAVERSALS  USING 
PATH  ANALYSIS  DATA 


Test  1 
Test  2 
Test  3 

Total 


Z_ABCDEFGHJKLMNPgRSTUV 


112111  1 1 
_ 1 1 1 1 1 1 1.1.1 1 1'l  £ 1 1 £ 1 1 - I 

122922343221563243311 


2 . Extended  Technique 

Preceding  the  arcs  labeled  D,  N,  P and  Q in  Figure  2 
are  decision  statements  involving  two  or  more  predicates  (e.g., 
"if  (A  and  B)  then") . The  basic  path  analysis  technique  pro- 
vided simply  for  traversal  of  each  arc  following  such  decisions 
(i.e.,  "A  and  B"  true,  and  "A  and  B"  false).  A more  thorough 
test  of  a bi-conditional  decision  would  execute  the  decision 
statement  under  the  four  truth  combinations  for  the  two  predi- 
cates (A  true  and  B false,  A true  and  B true,  A false  and  B 
true,  A false  and  B false);  similarly  a tri-conditional  decision 
could  be  executed  under  the  eight  truth  combinations  for  the 


/ 


66 


three  predicates. 

Analysis  of  the  appropriate  path  predicates  identified 
four  additional  test  cases  [Table  VIII)  which,  when  added  to 
the  three  cases  selected  by  the  basic  technique,  ensure  execution 
of  multi-condition  decision  statements  under  all  [possible) 
combinations  of  truth  values  for  the  decision  predicates.  Table 
IX  presents  the  arc  traversals  recorded  for  the  additional  tests. 

No  program  errors  were  detected.  The  total  additional 
effort  to  select  the  additional  cases  was  0.9  man-hours; 
therefore,  the  total  time  to  apply  the  extended  path  analysis 
method  was  2.2  hours.  The  additional  tests  required  0.18 
seconds  of  CPU  time,  for  a total  CPU  time  of  0.23  seconds  for 
the  extended  method. 


TABLE  VIII 

TEST  CASES  IDENTIFIED  BY 
EXTENDED  PATH  ANALYSIS 


Test  Length 

Number  of  Text  Text 


4 257 

5 3 aaa 

6 5 baaab 

7 160  * 


*Any  string  of  160 
..haracters 


TABLE  IX 


ARC  TRAVERSALS  USING 
EXTENDED  PATH  ANALYSIS  DATA 


Arc: 


ZABCDEFGHJ 


Test  4 
Test  5 
Test  6 
Test  7 


113  112  1 

115112212 
1 2 160  2 1 1 158  158 


Total, 

Tests  1-7  2 5 6 177  6 5 8 164  5 162 


K L_  _N_  _P_  _Q_  _R_  _S_  _T_  U_  _Y_ 

1 3 2 13  1 

1123  213  1 

13  11  1 1 

55  8 13  366  10  314 

E.  INDEPENDENT  SUB -STRUCTURES 

The  techniques  described  in  Chapter  III,  Section  E,  were 
applied  to  the  six  significant  procedures  of  the  example  program 
to  identify  control  paths  for  testing  based  on  the  independent 
language  constructs  of  the  procedures.  A spanning  tree  (consis- 
ting of  all  nodes  but  containing  no  circuits)  was  constructed 
corresponding  to  each  procedure  control  flow  graph  presented  in 
Figure  2 (Chapter  III);  the  arcs  of  the  spanning  tree  were 
considered  as  branches.  The  remaining  arcs  of  the  parent  graphs 
were  considered  to  be  chords,  with  a single  independent  circuit 
or  language  construct  corresponding  to  each.  The  fundamental 


matrices  for  the  six  procedures  are  presented  below;  the  rows 
are  labeled  with  the  language  construct  names  of  the  fundamental 
circuits;  the  columns  are  headed  with  the  arc  (branches  and 
chords)  labels.  If  a fundamental  matrix  has  n rows,  the  first 
n column  labels  from  the  left  are  the  chords  and  the  remaining 
column  labels  are  the  branches.  The  matrix  entries  have  the 
meanings  described  earlier. 


Procedure  "initialize": 

f e a b c d 
101110  main-line 
010-101  if-then 


Procedure  "read-^and-^write-^-input^-cards" : 

hdfabceg 
10000001  main-line 
01000100  while-do 
00101010  for 

Procedure  "palindrome^check" : 
nfljmabcdeghik 

10000110000000  main- line 
010000001-10000  if-then 
0010000000-1101  if-then 
0001000000001-1  if-then 
00001001011000  for 

Procedure  "continued-checking" : 


j fgabcdehi 
1001000011  main-line 
01000-11-100  if-then-else 
0010110100  while-do 








Procedure  "record+palindrome" : 


ft 

I 


n 

d 

h 

i 

m 

a 

b 

c 

e 

f 

g 

j 

k 

1 

1 

0 

0 

0 

0 

1 

0 

0 

0 

0 

0 

1 

1 

0 

main- line 

0 

1 

0 

0 

0 

0 

0 

1 

-1 

0 

-1 

0 

0 

0 

if-then-else 

0 

0 

1 

0 

0 

0 

0 

0 

0 

1 

-1 

0 

0 

0 

if-then 

0 

0 

0 

1 

0 

0 

1 

0 

1 

0 

1 

0 

0 

0 

for 

0 

0 

0 

0 

1 

0 

0 

0 

0 

0 

0 

0 

-1 

1 

if-then 

Procedure  " 

'main": 

g e a b 

c d 

f 

10  11 

0 1 

1 

main-line 

0 10-1 

1 -1 

0 

if-then-else 

The  control  paths  for  testing  were  selected  by  using  the  rows 
(fundamental  circuits)  and  all  linear  combinations  of  rows  having 
one  or  more  branches  in  common  to  identify  sequences  of  arcs  which 
should  be  tested.  The  paths  for  each  procedure  that  were  selected 
in  this  manner  are  presented  below;  paths  are  identified  here  in 
a node-to-node  format  (node  numbers  correspond  to  those  in  Figure 
2). 


Procedure  "initialize": 

1-2-3 

1-2-4-5 


Procedure  "read«-and-*-write-<-input-<-cards" : 


■L-4-0-0-4-0  * 

1-2- 3-4- 3- 5-2-6 


Procedure  "palindrome-'-check" : 

1-2-10  * 

1-2-3-4-5-9-2-10 

1-2-3-5-2-9-10 

1-2-3-5-6-7-8-9-2-10 

1-2-3-5-6-8-9-2-10 


m i 
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Procedure  "continue+checking" : 
1-2-7-8 

1-2-3-4-6-2-7-8 

1-2-3-5-6-2-7-8 


Procedure  "record«-palindrome" : 

1-2-8-9-10  * 

1-2-8-10 

1-2-3-5-7-2-8-10 

1-2-3-4-6-7-2-8-9-10 

1-2-3-4-7-2-8-9-10 

Procedure  ’’main" : 

1-2- 3-5-6 

1-2-4-5-6 

Path  predicates  were  established  for  the  control  paths 
listed  above  and  test  cases  were  selected  to  force  their 
traversal.  The  paths  above  followed  by  have  path  predicates 
which  cannot  be  satisfied  by  any  input  data;  the  given  execution 
sequence  is  impossible  for  any  allowable  input.  The  minimal  set 
of  test  cases  selected  to  satisfy  the  path  predicates  is  presented 
in  Table  X.  Dynamic  testing  with  these  test  cases  revealed  no 
program  errors;  0.12  seconds  of  CPU  time  were  required  for  the 
tests.  Table  XI  describes  the  allocation  of  the  2.2  man-hours 
of  effort  expended  in  the  application  of  this  method. 
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TABLE  X 


TEST  CASES  IDENTIFIED  BY 
INDEPENDENT  SUB -STRUCTURES  METHOD 


Test 

Length 

Number 

of  text 

Text 

1 

1 

- - 

2 

2 

xy 

3 

2 

aa 

4 

3 

aba 

5 

3 

abc 

6 

7 

aabbbba 

TABLE  XI 

TIMES  TO  APPLY  METHOD  OF 

INDEPENDENT  SUBSTRUCTURES 

Task  Accomplished  or 

Procedure  Shown  Man-Hours 


"initialize" 

" r e a d-«- an  d-^  w r i t e i np  u t ■«- c a r d s " 
"palindrome+check" 
"continue-*-checking" 
"record«-pal  indrome" 

"main" 

Conduct  dynamic  tests 
Total 


For  purposes  of  comparison  of  the  degree 
tests  conducted  by  this  method  with  that  of  the  path  analysis 
tests,  the  instrumented  version  of  the  example  program  was 
executed  with  the  test  cases  from  Table  X;  the  results  are 
given  in  Table  XII. 


0.1 

0.2 

0.6 

0.3 

0.7 

0.1 

0.2 

2.2 


of  arc  coverage  of 
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TABLE  XII 


ARC  TRAVERSALS  USING 


INDEPENDENT  SUB -STRUCTURES  DATA 


Total 


F.  INTUITIVE  TESTS 

The  intuitive  test  data  selected  prior  to  conduct  of  the 
previous  experimental  demonstrations  of  correctness  were  used 
for  dynamic  testing.  No  program  errors  were  revealed.  For 
purposes  of  comparison  of  the  degree  of  coverage  with  other 
methods.  Table  XIII  presents  the  results  of  execution  of  the 
instrumented  program  with  the  intuitive  test  data  listed  in 
Table  II  (Chapter  III,  Section  A).  The  selection  and  testing 
of  these  data  required  0.7  man-hours  of  effort;  the  tests 
consumed  0.44  seconds  of  CPU  time.. 


TABLE  XIII 


ARC  TRAVERSALS  USING 
INTUITIVE  DATA 


1 

Arc: 

Z_ 

A 

B 

C 

D 

E 

F 

G 

H 

J 

Test  1 

1 

1 

2 

1 

1 

1 

Test  2 
Test  3 

1 

1 

1 

3 

1 

1 

2 

1 

Test  4 
Test  5 

1 

1 

4 

256 

4 

1 

3 

252 

3 

251 

Test  6 

1 

1 

IS 

1 

1 

14 

13 

Test  7 

1 

2 

100 

2 

1 

1 

98 

98 

Test  8 

1 

4 

256 

4 

1 

1 

254 

254 

Total, 
Tests  1 

-8 

2 

6 

13 

632 

13 

6 

6 

620 

4 

616 

1 

Arc: 

K 

L 

M 

N 

-P-  JL 

R 

_S T U_ 

V 

Test  1 

1 

1 

1 

1 

Test  2 
Test  3 

1 

1 

1 

1 

Test  4 
Test  5 

1 

14 

6 

6 

l i 

10 

5 1 

1 

Test  6 

1 

1 

Test  7 

1 

49 

1 

1 

1 

Test  8 

1 

127 

1 

1 

1 

Total , 
Tests  1 

-8 

6 

190 

6 

10 

l l 

10 

9 11 

5 
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V.  CONCLUSIONS  AND  RECOMMENDATIONS 


A.  COMPARISON  OF  METHODS 
1.  Level  of  Effort 

Table  XIV  is  a summary  of  the  man-hours  of  effort  required 
for  each  method  of  demonstrating  the  correctness  of  the  example 
program,  broken  down  by  procedure  for  those  methods  where  pro- 
cedures were  examined  individually.  The  cyclomat ic  number  and 
number  of  statements  for  each  procedure  are  included  in  the  table 
as  measures  of  procedure  complexity.  The  times  to  apply  the 
verification  techniques  are  to  be  compared  with  one  another  and 
with  original  program  development  times  of  5.0  hours  to  design, 

7.0  hours  to  code,  4.0  hours  to  debug,  and  5.8  hours  to  test  (21.8 
hours  total) . 


TABLE  XIV 


SUMMARY  OF  TIMES 
TO  DEMONSTRATE  CORRECTNESS 


Cyclomatic 


Time  (Man-Hours)  Per 


Task  or 

Number  and 

Method 

Procedure 

No.  of  Stmts 

A 

B 

C 

D_ 

E 

Formalize  output 

- 

Specification 

0.8 

0.8 

- - 

- 

- 

"initialize" 

2 ; 14 

0.8 

0.2 

- 

0.1 

Show  termination 

of  utilities 

- 

0.6 

- 

- 

- 

- 

"read*-and«-write ..." 

3 ; 18 

4.2 

0.7 

- 

- 

0.2 

"pal  indr  ome«-check" 

5 ; 7 

1.6 

0.9 

- 

- 

0.6 

"cont  inue-*-  checking" 

3 ; 15 

1.8 

1.3 

- 

- 

0.3 

"record-*-pal  indrome" 

5 ; 21 

3.5 

3.2 

- 

- 

0.7 

"main" 

2 ; 6 

0.2 

0.4 

- 

0.1 

Conduct  dynamic 

testing 

*“ 

A 

0.2 

Total 

13.5 

7.5 

1.3  2 

.2 

2.2 

Methods : 

A - Formal  proof 

B - Condition  table/distributed  correctness 
C - Basic  path  analysis 
D - Extended  path  analysis 
E - Independent  sub -structures 
* - Test  time  included  in  times  for  procedures. 


Quite  expectedly  the  two  more  formalized  verification  tech- 
niques (proof  and  condition  table  method)  required  considerably 
more  effort  than  any  of  the  other  methods,  and  in  fact  required 
more  hours  of  effort  than  were  involved  in  program  design  (time 
to  construct  the  proof  exceeded  even  the  time  to  design  and  code) . 
As  the  subsequent  discussion  of  the  thoroughness  of  each  method 
indicates,  these  two  methods  provide  higher  confidence  in  program 
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correctness  than  the  other  simpler  and  more  mechanical  methods. 

The  question  becomes  whether  the  increased  return  from  formal 
methodology  is  worth  the  cost.  The  complexity  and  importance  of 
the  software,  budget  constraints,  and  several  other  factors  come 
to  bear  on  the  decision,  and  the  decision  should  be  made  separately 
for  each  software  project. 

From  a philosophical  standpoint  at  least,  ex  post  facto 
proof  of  correctness  is  inefficient  because  of  a great  deal  of 
duplication  of  effort.  The  logical  process  of  constructing  the 
proof,  in  the  case  of  this  experiment  and  in  general,  requires 
at  least  as  thorough  an  understanding  of  the  application  and  of 
the  program  control  structure  and  data  flow  as  does  the  design 
and  implementation  effort.  The  logical  techniques  of  proof  can 
give  excellent  evidence  as  to  the  correctness  of  programs  (but 
not  conclusive;  see  Ref.  15  and  others)  and  are  clearly  desirable 
for  use,  but  a higher  cost  effectiveness  than  that  suggested  from 
this  experiment  is  required.  Possibilities  include  attempts  to 
automate  ex  post  facto  proving  of  correctness  or  to  introduce  the 
lgocal  techniques  in  the  design  and  implementation  of  software. 
These  alternatives  are  major  areas  of  research;  brief  mention 
is  made  here. 

Structured  programming  concepts,  advanced  language  design, 
and  formal  definition  of  requirements  are  examples  of  software 
engineering  efforts  to  emphasize  the  use  of  logical  methods  in 
the  design  and  implementation  of  provable  programs.  Mann  has 
discussed  the  feasibility  of  using  logic  techniques  to  generate 
programs  guaranteed  to  satisfy  the  output  specifications,  thus 
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obviating  the  need  for  ex  post  facto  verification  (26) . It  is 
in  this  area  that  the  greatest  promise  for  correct  software  is 
to  be  found. 

Several  aspects  of  the  formal  proof  process  may  be  subject 
to  automation.  Manna  discussed  briefly  in  Reference  26  (pp.  203- 
204)  progress  that  has  been  made  in  systems  to  automatically 
generate  invariant  assertions  and  verification  conditions  and 
systems  (theorem  provers)  to  prove  the  verification  conditions. 

Both  tasks  are  formidable  and  it  is  unlikely  that  full  automation 
can  be  achieved;  yet,  partial  solutions  would  be  extremely  help- 
ful in  reducing  the  tedium  involved  in  the  process  of  formal 
proof.  The  limitations  on  automation  of  the  process  are  succinctly 
stated  by  Dijkstra  (9) : 

The  distorting  spell  of  speed  still  seems  to 
take  its  victims.  We  see  automatic  theorem 
provers  proving  toy  theorems,  we  see  automatic 
program  verifiers  verifying  toy  programs  and 
one  observes  the  honest  expectation  that  with 
faster  machines  with  lots  of  concurrent  processing, 
the  life-size  problems  will  come  within  reach  as 
well.  But,  honest  as  these  expectations  may  be, 
are  they  justified?  I sometimes  wonder... 

The  level  of  effort  required  to  apply  the  condition  table 
method  of  selecting  test  data  in  a fashion  as  nearly  reliable 
and  valid  as  possible  (according  to  the  theory  of  testing  dis- 
cussed in  Chapter  II)  compares  more  favorably  with  the  original 


program  design  effort.  If  similar  relationships  exist  for  large 
scale  applications,  the  method  is  likely  to  be  effective  at 
reducing  the  life  cycle  cost  of  software  as  the  method  appeared 
in  these  experiments  to  offer  a greater  ability  to  locate  errors 
than  less  formal  methods,  thus  reducing  maintenance  costs. 
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Evidence  of  the  cost  effectiveness  of  this  or  similar  formalized 
test  case  selection  criteria  is  required  from  large-scale  appli- 
cations in  a commercial  environment  to  be  conclusive. 

It  is  interesting  to  relate  the  effort  required  to  apply 
to  individual  procedures  the  methods  A,  B,  and  E (Table  XIV)  with 
the  complexity  measures  of  these  procedures.  While  the  sample 
size  of  the  data  collected  here  is  too  small  for  statistical 
significance  and  the  data  are  distorted  by  the  presence  of  learning 
curves  (e.g.,  procedure  "read-*-and^write^input^cards"  was  the 
first  procedure  with  loops  proven  correct,  and  several  false 
starts  were  included  in  the  4.2  hours  of  effort),  there  did  appear 
to  be  a relationship  between  complexity  and  effort  to  demonstrate 
correctness.  Although  the  level  of  effort  did  not  linearly 
relate  to  the  magnitude  of  either  of  the  measures  of  complexity 
shown  in  Table  XIV,  effort  appeared  to  increase  with  increasing 
complexity,  and  the  cyclomatic  number  appeared  to  be  a better 
predictor  of  effort  than  did  the  number  of  statements. 

2 . Thoroughness  of  Verification 

As  discussed  in  Section  B of  Chapter  II,  the  requirement 
for  an  ideal  test  according  to  the  theory  of  testing  presented 
in  that  chapter  may  be  satisfied  in 'several  ways.  Selecting  no 
test  data  and  proving  that  the  program  is  correct  (i.e.,  contains 
no  errors)  clearly  satisfies  the  criteria  for  an  ideal  test. 
Accordingly,  on  the  basis  of  the  proof  of  correctness  constructed 
as  part  of  this  experiment  it  can  be  stated  that  the  example 
program  is  correct  as  written,  provided  the  proof  contains  no 
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errors  and  no  unwarranted  assumptions.  That  proviso  is  not  easily 
ignored;  Reference  15  is  only  one  source  of  examples  of  programs 
"proven"  correct  which  in  fact  contain  errors.  Nonetheless,  the 
proof  provides  a high  degree  of  confidence  in  the  correctness  of 
the  example  program. 

The  several  path  analysis  strategies,  including  the  identi- 
fication of  paths  for  testing  by  decomposition  into  independent 
sub-structures,  did  not  include  any  attempt  to  show  the  reliability 
and  validity  of  the  test  cases  selected.  Consideration  of  possible 
errors  in  the  program,  particularly  in  the  statements  controlling 
control  flow,  revealed  several  potential  errors  that  would  be 
detected  using  the  test  cases  of  the  extended  path  analysis  tech- 
nique (multi-conditions  emphasized)  but  not  by  one  or  both  of 
the  other  two  path  analysis  methods. 

For  example’,  if  the  statement 

while  ((ix<*length«-of-<-text)  and 
(bufferpositionccard  limit))  do 

in  the  procedure  "read«-and-*-write-*-input«-cards"  had  the  incorrect 
relational  operator  "bufferposition<*"  vice  "<",  none  of  the  test 
cases  selected  by  the  basic  path  analysis  technique  or  by  sub- 
structure analysis  would  reveal  the  error  (no  string  sufficiently 
long) , but  test  7 (length  160)  of  the  extended  path  analysis 
method  would  reveal  the  error  through  a run-time  indexing  error 
on  assigning  the  81st  character  to  "text."  Similarly,  if  in 

procedure  "record«-palindrome"  the  statement 

if  ( (f  irst>*begin+-of«-palindrome  (i) ) and 
(last<=end«-of-*-palindrome(i)) ) then 
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omitted  the  "or  equal"  test  from  the  ">■"  and  "<»"  operators, 
the  basic  and  extended  path  analysis  test  case  3 ("baaaaca") 
would  reveal  the  error  by  recording  three  palindromes  (baaaaca, 
baaaaca , and  baaaaca)  which  are  included  in  the  larger  palindrome 
(baaaaca)  and  should  be  ignored.  The  error  would  not  be  revealed 
by  the  test  data  selected  from  independent  circuit  considerations. 

Because  there  exist  potential  errors  that  would  not  be 
revealed  by  the  path  analysis  test  sets  (including  the  extended 
method  set,  as  will  be  shown  in  the  next  paragraph),  the  criteria 
as  applied  in  these  experiments  were  not  valid  and  reliable  in 
the  meaning  of  testing  theory.  While  the  particular  errors 
revealed  or  not  revealed  in  these  experiments  are  peculiar  to 
the  program  under  test,  selection  of  test  data  by  any  means  of 
path  analysis  other  than  exhaustive  path  testing  cannot  be  ex- 
pected to  detect  all  program  errors. 

The  test  cases  selected  by  condition  tables  were  capable  of 
revealing  all  of  the  errors  considered  above,  including  the  two 
specific  errors  mentioned  (test  cases  4,  5,6  and  7 for  the 
first,  test  23  for  the  second).  Additionally,  there  were  po- 
tential errors  which  could  be  detected  through  dynamic  testing 
only  by  the  test  cases  selected  by  this  method.  These  results 
are  peculiar  to  the  specific  program  under  test  but  are  consid- 
ered representative  of  the  capabilities  of  the  several  methods. 

(It  is  not  suggested  that  the  condition  table  method  is  in 
general  capable  of  revealing  all  errors.) 

For  example,  if  in  procedure  "continue+checking"  the 


statement 


while  ((first>l)  and  (last<length«-of-«-text) 
and  (palindrome*true) ) do 


mistakenly  contained  "last<="  vice  "last<,"  test  case  3 ("baaaaca' ) 
of  the  path  analysis  techniques  and  test  6 ("aabbbba")  of  the  in- 
dependent circuit  method  would  both  erroneously  cause  traversal 
of  the  arc  "M"  (see  Figure  2;  arc  "M"  sets  palindrome"  equal  to 
the  value  "false")  during  the  calls  to  the  procedure  with  string 
(first, last)  being  the  underscored  palindrome,  but  there  would 
be  no  external  effect  noticeable  to  the  tester  and  the  error 
(which  has  potential  to  cause  an  indexing  error)  would  go  unde- 
tected. However,  the  condition  table  for  assertion  B17-18  (para- 
graph E.l.  of  Appendix  B)  would  cause  the  error  to  be  noticed  when 
examining  the  predicates  of  the  assertion  as  required  by  the  method 
during  execution  of  test  element  "abb." 

This  localization  of  test  effort  afforded  by  using  the  prin- 
ciple of  distributed  correctness  is  one  of  the  most  powerful 
aspects  of  the  method  as  used  in  this  experiment.  While  the 
localization  added  to  the  effort  required  (full  knowledge  of  the 
program’s  internal  structure  was  required),  it  was  the  localization 
of  analysis  that  enabled  some  positive  statements  to  be  made  re- 
garding the  validity  and  reliability  of  the  selected  test  data. 
While  in  several  cases  it  was  not  possible  to  prove  the  generali- 
zation assertion  for  the  selected  test  data  assertion,  in  each 
case  a high  degree  of  confidence  was  established  that  the  test 
data  did  in  fact  partition  the  input  domain  for  the  program  frag- 
ment under  consideration  into  equivalence  classes  with  respect 
to  program  operation. 


From  this  confidence  and  the  fact  that  no  input  data  were 
excluded  from  selection,  it  was  concluded  that  the  criterion 
for  selecting  test  data  as  applied  to  this  program  was  valid 
and  "almost  reliable."  Additional  work  in  identifying  theorems 
which  can  be  used  in  generalizing  from  specific  test  data  to 
the  entire  input  domain  is  needed  and  offers  an  opportunity  for 
a highly  reliable  testing  methodology. 

The  error  data  provided  in  Table  I,  from  the  original  program 
development  process,  was  not  useful  for  discriminating  among 
the  methods  applied  in  verifying  the  program.  Each  method 
would  detect  the  presence  of  the  errors  described  in  Table  I. 

It  is  interesting  that  the  set  of  intuitive  test  data  (Table 
II)  selected  prior  to  thorough  analysis  of  the  example  program 
is  capable  of  revealing  all  of  the  errors  considered,  including 
the  "last<="  vice  "last<"  error  in  "continued-checking"  (a  run- 
time indexing  error  would  occur  for  "text (last+1) " for  test  case 
8 as  a result  of  that  error).  However,  the  method  of  casual 
or  intuitive  selection  of  test  data  is  not  in  any  way  desirable; 
the  error  detection  capability  in  this  case  is  due  only  to  luck 
and  the  relative  simplicity  of  the  program  function,  and  the 
cost-effectiveness  penalty  in  terms  of  CPU  time  expended  on 
test  cases  which  are  in  fact  not  distinguishable  can  be  severe. 

B.  SUMMARY  OF  CONCLUSIONS  AND  RECOMMENDATIONS 

This  section  presents  a summary  of  the  conclusions  drawn  in 
the  main  text  of  this  thesis. 
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1.  The  need  exists  for  greater  relative  emphasis  on  design 
and  implementation  techniques  as  compared  to  verification  tech- 


niques (pages  13  and  77-78). 

2.  Significant  efforts  are  required  in  applying  the  disci- 
pline of  software  engineering  toward  refinement  or  replacement 
of  the  verification  methods  now  in  use  (page  14). 

3.  The  formal  proof  of  correctness  and  the  application  of 
the  condition  table  method  based  on  distributed  correctness 
required  significantly  more  effort  than  the  path  analysis  stra- 
tegies (page  76 ) . 

4.  There  are  serious  limitations  on  the  feasibility  of  auto- 
mating the  process  of  formally  proving  program  correctness  (page  ' 
78) . 

5.  There  was  some  positive  correlation  of  the  level  of 
effort  required  to  demonstrate  correctness  with  the  complexity 
of  procedures  as  represented  by  the  cyclomatic  number  (page  79). 

6.  The  proof  of  correctness  of  the  example  program  provides 
a high  degree  of  confidence  in  the  correctness  of  the  program 
(page  80)  • 

7.  The  path  analysis  strategies  as  applied  in  these  experi- 
ments did  not  provide  reliable  and  valid  criteria  for  selecting 
test  cases.  Selection  of  test  data  by  any  means  of  path  analysis 
other  than  exhaustive  path  testing  cannot  be  expected  to  detect 
all  program  errors  (page  81  )• 

8.  The  condition  table  method  using  the  principle  of  dis- 
tributed correctness  afforded  a valid  and  "almost  reliable" 
criterion  for  test  case  selection  (page  83 ) • 
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APPENDIX  A 


FORMAL  PROOF 

A.  ASSUMPTIONS,  ABBREVIATIONS,  AND  NOTATION 

Several  assumptions  about  the  example  program  were  made  in 
addition  to  those  verified  by  static  analysis  and  those  mentioned 
in  Section  B of  Chapter  IV.  It  was  assumed  that  the  host  environ- 
ment of  the  program  (compiler  and  operating  system)  was  error- - 
free.  All  input  data  read  by  the  program  were  assumed  type  com- 
patible with  variables  - integers  for  integer  variables,  valid 
printable  characters  (including  blanks)  for  string  variables.  It 
was  assumed  that  the  number  of  characters  following  the  integer 
stating  the  length  of  the  input  character  string  was  equal  to 
that  integer.  The  domain  of  the  numerical  values  in  all  predi- 
cate formulae  in  the  proof  was  assumed  to  be  the  integers  only, 
and  only  interger  division  was  intended;  the  operators  div  and 
rem  were  used  to  represent  the  integer  quotient  and  remainder, 
respectively. 

Because  several  of  the  program  variable  names  are  verbose, 

the  abbreviations  listed  below  were  used  in  the  assertions  and 

formulae  of  the  proof: 

-l  length  of  text 

-It  cardlimit 

-cb  cardbuffer 

-n  number^-of^input^-cards 

-c  card-^counter 

-bp  bufferposition 

-bop  begin-*-of«-palindrome 

-eop  end«-of-*-pal  indrome 

-p  palindrome 


Figures  3 through  8,  shown  in  the  following  pages,  are 
listings  of  six  program  procedures  with  labeled  invariant  asser- 
tions inserted  for  purposes  of  the  proof.  Assertions  AO  and  A58 
are  the  program  input  and  output  assertions.  Assertions  are  con- 
tained within  braces  "{  },"  and  in  Figures  3 through  8 wherever 

successive  labeled  assertions  follow  a program  statement,  the 
intermediate  assertion  to  be  proved  at  that  point  is  a conjunction 
of  those  assertions.  Frequently  assertions  contain  within  the 
braces  the  names  (labels)  of  earlier  assertions;  the  meaning  im- 
plied is  a literal  replacement  of  the  label  with  its  earlier 
expansion.  In  the  terminology  of  Section  B of  Chapter  III,  the 
proof  presented  in  this  appendix  is  a proof  of  the  invarient 
statement : 

(AO)  program  {A58> 

This  terminology  and  that  for  rules  of  inference  (see  the  same 
section)  are  used  throughout  this  appendix. 

B.  ADDITIONAL  RULES  OF  INFERENCE 

As  mentioned  in  Chapter  III,  rules  of  inference  similar  to 
those  in  Reference  26  were  formulated  for  iterative  for  state- 
ments and  procedure  calls.  Those  rules  are  presented  here: 

1.  Iterative  Rule 

The  statement  for  C:*E  step  1^  until  L do  F is  logically 

equivalent  to  the  program  fragment: 

(P)  //an  assertion 

C:*E  //C a counter,  E an  expression 

LIMIT:»L  //L  an  expression 
{ I > //an  assertion 

more:  if  C>LIMIT  then  goto  fini 
~T  7’/Ioop  body 
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fini : 


C:»C+1 
goto  more 


//an  assertion 


Corresponding  to  this  form  of  the  statement,  the  rule  of  infer- 


ence is : 


P=*I,  {i  a C<» LIMIT}  F { I } , I A C> LIMIT 


{P}  for  statement  {Q> 


2.  Call  Rule 


All  procedures  in  the  example  program  pass  parameters  by 
value,  so  that  operations  on  the  formal  parameters  within  the 
procedure  body  do  not  affect  the  actual  parameters.  Global 
variables  may  however  be  modified  in  the  procedures.  The  nota- 
tion p(f,g)  represents  a procedure  p with  some  formal  parameters 
f which  operates  on  some  global  parameters  g;  the  procedure  has 
a body  F and  input  and  output  assertions  Q and  R.  A call  to 
the  procedure  with  actual  parameters  a is  denoted  by  call  p(a). 
S(a:  = f)  and  T(a:=*f)  are  the  assertions  in  the  calling  program 
located  before  and  after  the  call,  with  formal  parameter  names 
substituted  for  actual.  The  rule  of  inference  is: 

S (a : =f)  =$>  Q,  R =>T(a:=f),  {Q}  F {R} 

(S>  call  p(a)  {T> 

The  rule  is  essentially  a statement  that  a procedure  call  is 
proved  when  an  in-line  substitution  of  the  procedure  body  is 
shown  to  be  valid.  In  showing  that  R=^T(a:*f),  the  prover 
must  verify  that  global  variables  referenced  in  T but  not  in 
R are  not  modified  by  execution  of  the  procedure  body. 
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C.  PROCEDURES  TEXT1,2,3 

Because  these  procedures  do  not  contribute  to  the  essential 
program  performance  (as  was  determined  during  static  analysis) , 
only  a superficial  proof  of  correctness  was  performed.  It  was, 
however,  necessary  to  show  termination  in  order  to  verify  that 
program  execution  would  not  endlessly  loop  in  one  of  these  non- 
essential  procedures. 

1.  Input  Assertion:  {true}  i.e.,  no  restriction. 

2.  Output  Assertion:  {true};  i.e.,  no  restriction. 

3.  Verification  Condition: 

{true}  procedure  {true},  or  true  a.  null  =^true,  where 
null  is  a notation  for  program  statements  having  no  significant 
effect.  Proof  of  the  verification  condition  is  immediate. 

4.  Termination 


The  procedure  has  only  one  entry  and  one  exit  and  con- 
tains no  loops;  therefore,  it  terminates. 


D.  PROCEDURE  BLANK^ LINES;  TERMINATION  OF  FOR  STATEMENTS 

Similarly,  only  a superficial  proof  of  this  non-essential 
procedure  was  performed. 

1.  Input  Assertion:  {n>0 } . 

2.  Output  Assertion:  {true}  ; i.e.,  no  restriction. 

3.  Verification  Condition:  {n>0}  procedure  {true}. 

4.  Proof 


Regardless  of  the  value  of  the  antecedent,  the  consequent 
remains  the  logical  value  true;  therefore,  the  implication 
holds . 
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S.  Termination 


Termination  is  assured  if  the  error  exit  at  the  state-  ' 
ment  "assert(n>0)"  is  not  taken,  and  if  the  for  loop  following 
terminates.  The  error  exit  is  taken  when  n<»0.  The  input 
assertion  guarantees  n 0;  therefore,  the  error  exit  is  not  taken. 

The  for  statement  loop  terminates  whenever  the  value  of  the 
loop  counter  exceeds  some  pre-defined  limit.  Informally  it  is 
clear  that,  given  a finite  starting  value  and  finite  limit  for 
the  counter  and  given  that  the  loop  body  itself  terminates  (as 
it  does  in  this  case  - no  nested  loops)  either  the  loop  body  is 
not  executed  at  all  (starting  value  exceeds  limit)  or  eventually 
the  counter  must  exceed  the  limit  (since  it  is  incremently  by  1 
following  each  loop  execution,  by  virtue  of  the  "step  1"  portion 
of  the  statement,  and  no  other  assignments  are  made  to  the  counter 
in  the  loop  body),  and  the  loop  will  terminate. 

More  formally,  let  EXP-LIMIT+1-C0UNTER  be  a termination 
expression,  let  N be  the  set  of  natural  numbers,  and  let  > be 
the  usual  greater-than  relation.  Note  that  N is  well-ordered 
by  >.  In  all  implementations  of  a for  statement  of  the  type 
described  in  the  iterative  rule  of  inference,  if  the  initial 
value  of  EXP  is  zero  or  not  contained  in  N (i.e.,  negative), 
then  the  loop  body  is  not  executed  and  termination  is  assured. 
Likewise,  if  the  initial  value  of  EXP>=1,  the  loop  body  is 
executed,  COUNTER  is  incremented,  and  the  subsequent  value  of 
EXP  is  (EXP-1) e N.  Since  an  infinite  decreasing  sequence  of 
values  of  EXP  € N is  not  possible  (N  is  well  ordered) , the  loop 
must  terminate  (EXP-0). 


90 


I 


_ ! — - 

An  important  conclusion  can  be  reached  from  the  above  proof 
of  termination  of  the  for  statement  in  procedure  "blank  lines": 
every  occurrence  of  a statement  of  the  type  for  C:*E  step  1^  until 
L do  F terminates  provided  the  program  fragment  F terminates. 

E.  PROCEDURE  WRITE«-ALL-<-PAL INDROMES 

As  in  the  preceding  cases,  only  a superficial  proof  was 
required  for  this  non-essential  procedure  (non-essential  in  terms 
of  the  palindrome  search  problem). 

1.  Input  Assertion:  (true). 

2.  Output  Assertion:  (true). 

3.  Verification  Condition: 

(true)  procedure  (true).  The  proof  is  immediate. 

4 . Termination 

The  procedure  has  only  one  entry  and  one  exit.  It  con- 
tains no  loops  other  than  for  statements  (which  have  been  shown 
to  terminate);  therefore  the  procedure  terminates. 

F.  PROCEDURE  INITIALIZE 

Figure  3 is  a listing  of  procedure  "initialize"  with  the 
necessary  assertions  included.  The  notation  "input (A)"  refers 
to  the  data  value  in  the  input  stream  which  will  be  assigned 
to  the  program  variable  "£". 

1.  Input  Assertion:  Assertion  Al. 

2.  Output  Assertion:  Assertion  A2. 

3.  Verification  Condition:  (Al)  procedure  (A2). 

4.  Proof. 

The  proof  of  this  verification  condition  follows  directly 
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procedure  Initialize) 

coaatat  Initialise  all  variakUa,  read  length_o f _ text , write 
kegia 

C 2<  3 lnpot(  1)  < =‘236  A ca*#  1 
text  1 1 
Jx»» It 

pa  1 lndroaaa  -counter  t ■ 1 1 
cardl  iaalt : *W| 
intf le ldaixe : »S* 
read! length— of—text) « 

if  (< long th_of_ text  < 2)  or  ( length_o f -text  > 286))  then 
ketia 

wr  1 te(  * 1 1 lega 1 input* ", 

* length  of  input  string  is:  ",  length -of— text) t 
aaaertf falae) i 
end  | 

cardbuf for : * * *t 

f 2<  = 1<=236  A ca*9  A jx»l  A lt>M  A cb^blank  ) 
end  initialize* 


FIGURE  3 


PROCEDURE  INITIALIZE 


from  the  semantic  meaning  of  the  assignment  statements  and  read 
statement.  Each  predicate  of  the  output  assertion  is  just  an 
expression  of  an  assignment  made  in  the  procedure  body,  except 
the  term  "ca*0",  which  is  just  a restatement  of  an  input  asser- 
tion predicate.  The  proof  variable  "ca"  is  discussed  in  the 
proof  of  the  next  procedure.  A series  of  intermediate  assertions 
could  have  been  made,  one  following  each  assignment  statement, 
to  more  formally  indicate  the  method  of  proof.  In  particular, 
the  i^f  statement  has  been  ignored  in  the  preceding  simple 
proof;  it  is  discussed  in  the  termination  proof. 

Note  that  in  Algol-W  the  meaning  of  an  assignment  of  a 
single  character  value  to  a string  of  length  greater  than  one 
is  to  pad  out  the  string  variable  on  the  right  with  blanks;  thus 
the  predicate  "cb=blank",  following  the  assignment  statement 
"cardbuf fer : ="  ","  means  that  "cb"  initially  contains  80  blanks 
("cb"  is  an  abbreviation  for  "cardbuf fer" , a string  array  of  80 
characters) . 

5 . Termination 

The  procedure  is  a concatenation  of  assignment  statements, 
a read  statement,  a call  to  procedure  "textl",  and  an  if  state- 
ment containing  a potential  error  exit  (:the  assert  statement) . 
Because  ’’textl"  terminates,  "initialize"  will  terminate  at  the 
output  assertion  provided  the  error  exit  is  not  taken.  Since 
assertion  A1  ensures  that  2<*£<=256,  the  compound  statement 
forming  the  consequent  of  the  i_f  statement  cannot  be  executed; 
thus  the  error  exit  cannot  be  taken,  and  the  procedure  does 
terminate . 
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G.  PROCEDURE-READ-AND^WRITE-INPUTVCARDS 


Figure  4 contains  the  assertions  for  this  procedure;  several 
of  the  assertions  use  abbreviations  listed  earlier  in  this 
appendix.  A proof  variable  "ca" , a variable  that  is  not  an 
actual  program  variable,  was  used  in  this  proof  to  represent 
the  characters  assigned,  or  the  number  of  characters  that  had 
been  read  from  the  input  stream  and  transferred  into  the  string 
array  "text". 

1.  Input  Assertion:  A4 

2.  Output  Assertion:  A15 

3.  Intermediate  Assertions: 

A5  through  A14.  Verification  conditions  are  provided 
for  all  possible  assertion- to-assertion  paths  in  the  following 
paragraphs . 

4.  Path  A4  to  AS 

The  verification  condition  is: 

2<=£<=256  A ca=0  a.  £t=80  A cb=blank 
A n=((ft-l)div  fct)+l  a ix=l 

2<  = 5,<  = 256  A ca=0  A £t=80  a ix=l 
a n>=l  A n= ( (t-1) div80) +1 

Given  the  truth  of  the  antecedents,  the  consequents  are  shown 
true  as  follows: 

a.  2<=Jl<*256  A ca=0  a £t=  80  a ix=  1 : 
these  predicates  are  just  a restatement  of  antecedents  which 
have  not  been  affected  by  the  intervening  program  statements. 
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procedure  read— and— wr 1 te—input— cards ; 

coaotnt  read  Input  carda  accord in«  to  (loan  lenfth— o f-text : 
begin 


A4-*  ( 2<  3 1<  *256  A ca3#  A It = 89  A cb= blank  3 

Integer  number— of— Input— cards ; 

number— of— input— cards : 3 ! length— o f— text  - 1)  dlv  card  limit  * 1: 
ix:*ii  comment  reaet  text  index; 

AS:  C 2<«  1<»236  A ca>«  A lt«89  A lx3  1 A n>3lA  n3  ( ( 1- l ) d i vB9  > + 1 3 

for  card— counter : 3 1 step  1 

A6:  t ( lx-l)rem8939  =>c*(  ( lx-1 ) d 1 v89) + l 3 

A7:  t &< 3 lx-l<  3 l A ( lx-I< 1 c<  =n)  ) 

A8:  C ~(Uz-l)r«a89«9)  c3(  Ux-1 ) d 1 v06)  +2  3 

A'' : t ( lx- 13  1 =£>  c>n)  A ((lx-  1)  rem8939  V lx-l3l)  ) 

A19:  ( 2<  3 1<  =286  A ca>ir-l  A lt389A  n>3lA  n3  ( ( 1- 1)  d iv80)  + 1 3 

until  number— of— Input— cards  do 
be  grin 

write! card— counter) : 
wr  1 teon(  * ")  » 
readcard( cardbuf fer) i 
wr 1 teont cardbuf fer ) t 

buf ferpos 1 t ion: 39;  comment  reaet  index: 

trill  le 

All:  { 9<  * bp< “it  9<»lx— 1<31  ( lx— l-bp)rem8939  A19 

cb3s tr ing  of  next  89  or  fewer  characters  3 

( ( lx< 3 length— of— text ) and  ( buf ferpos 1 1 lon< card  1 Imi t > ) do 
beer  in 

text! lx) : ^cardbuf fer!  buf  ferpos 1 1 ion  I 1) ; 

A12:  f 2<  3 1<  =256  A lt=89A  n>3l  A n=(  ( 1- 1 ) d 1 v89>  + 1 

A cb'atrlng  of  89  characters  3 
A13:  f ci* lx  A 9<  3bp< It  A 1<31x<31  a ( lx-1-bp) rem8939  3 

lx: 3 lx+ 1 : 

buf ferpos 1 1 Ion: 3 buf ferpos 1 1 ion* 1 1 

A 14:  ( A12  A 9<31x-1<*1a  ci*Ix-1  a t( bp=89  A ( lx- 1) rem8930)  V lx- 1= 13  3 

end;  comment  done  for  all  characters  on  a card: 

end;  comment  done  for  all  cards: 

A1S : C lx— 1*1  A ea* 1 A 2< 3 1<  3256  A lt*69  3 

end  read— and— wr 1 te_ Input— cards i 


FIGURE  4 

PROCEDURE  READ*- AND-*WRITE+-INPUT«- CARDS 
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b.  n« ( (£-1) div80) +1 : 
follows  from  n*((£-l)div  £t)+l  A £t*80. 


c.  n>«l: 
n*((£-l)div80)+l; 

£>-2  =%>  A-1>»1; 

5.-1  -1  (£-1) div80>*0 ; 

therefore  n>»l. 


5 . Path  AS  to  A6-10 


The  verification  condition  is: 

A5  a c*l  A6  a A7  A A8  a A9  A A10 
The  verification  condition  is  proved  by  considering  the  conse- 
quents one  at  a time: 

a.  (ix-l)rem80*O  c»( (ix-l)div80)+l  {A6}: 
from  A5,  ix*l; 

ix*l  -=^>  ( (ix-l)div80)  +1=0+1*1 ; 

because  c has  been  set  equal  to  1,  the  consequent  of  the  above 
conditional  is  true,  and  the  conditional  is  true  regardless  of 
the  truth  of  the  antecedent. 

b.  0<*ix-l<*£  { from  A7)  : 

ix*l  ix-l*0,  and  £>*2. 

c.  ix-l<£  ^ c<*n  {from  A7}  : 

c»l  and  n>*l,  therefore  c<*n,  and  the  conditional  must  hold. 

d.  — . ((ix-l)rem80-0)  c»( (ix-l)div80)+2  { A8}  : 

ix*l  ix-1-0;  thus  (ix-1) rem80-0  is  true; 

so  — 1( (ix-l)rem80»0)  is  false, 
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and  the  conditional  is  true. 

e.  (ix-1-2,  -=*>  c>n)  a.  ((ix-l)rem80-0  V ix-l-i)  (A9> 
ix-l»0  and  4>» 2,  so  ix-l-t  is  false,  and  the  conditional  is  true, 
and  (ix-l)rem80»0  is  true,  and  therefore  the  disjunction  is  true; 
thus,  A9  must  hold. 

f.  ca-ix-1  {from  A10}: 

ca-0  and  ix-1  is  sufficient  for  ca-ix-1. 

g.  the  remainder  of  assertion  A10: 

these  predicates  are  just  a restatement  of  antecedents  which 
have  not  been  affected  by  the  intervening  statement. 

6.  Path  A6-10  to  All 

The  verification  condition  is: 

A6  a A7  a A8  a A9  a A10  a c<*n  a bp-0 
a cb-string  of  next  80  or  fewer  characters  =?*  All 
Again  the  consequents  (predicates  of  All)  are  considered  one  at 
a time. 

a.  0<-bp<-tt: 

this  follows  from  bp-0  and  it- 80. 

b.  (ix-l-bp) rem80»0 : 

c<*n  — » (on)  ; 

—^(c>n)  a (ix-l-i  c>n)  — ■ (ix-l-£) ; 

—i  (ix-l-£)  A ( (ix-1) rem80-0  v ix-l»£)  =»  (ix-1) rem80-0 ; 
finally,  (ix-1) rem80«0  A bp-0  (ix-l-bp) rem80-0 , 
which  is  that  which  was  to  be  proved. 

c.  The  remainder  of  the  predicates: 


these  predicates  are  just  a restatement  of  antecedents  which 
have  not  been  affected  by  the  intervening  statements. 
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7.  Path  All  to  A12-13 

The  verification  condition  is: 

All  a ix<-A  a bp<At  a text(ix)»cb(bp|l)  A12  a A13 
The  consequents  of  the  verification  condition  are  considered 
one  at  a time. 

a.  ca«ix  {from  A13): 

ca*ix-l  a text(ix)*cb(bp|l)  is  sufficient  for  ca«ix  to  be  true. 
text(ix)  is  the  ix-th  character,  and  it  is  assigned  a value  in 
this  program  fragment  (that  it  is  the  proper  value  is  shown 
shortly).  If  ix-1  characters  have  been  previously  correctly 
assigned  to  text,  and  one  more  character  is  assigned,  then  ix 
characters  have  been  assigned  when  control  reaches  assertion  A13. 
In  Algol-W,  the  string  indexed  by  bp  1 1 is  a string  of  length  1 


(i.e.,  a character)  at  position  bp  in  the  larger  string  (cb) ; 
the  first  position  is  0,  and  the  80th  is  79.  0<*bp<Jlt  guarantees 
that  bp  is  in  range;  "cb=string  of  next  80  or  fewer  characters" 
ensures  that  the  proper  characters  are  in  the  buffer,  and 
(ix- 1-bp) rem80*0  means  that  ix  and  bp+1  (the  next  character  to 
be  assigned  in  text  and  the  next  character  in  the  buffer  avail- 
able for  assignment)  always  differ  by  a multiple  of  80,  which  is 
correct  when  an  80-character  buffer  is  used.  So  the  proper 
character  is  being  assigned  on  this  control  flow  path. 

b.  0<*bp<it  (from  A13}: 

0<-bp<»At  a bp<it  0<*bp<tt. 

c.  l<-ix<*4  (from  A13): 

0<»ix-l<-t  a ix<«£  ^ l<«ix<-t. 
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c.  l<»ix<-4  {from  A13}: 

0<«ix-l<»Jl  a ix<-4  =^l<»ix<»fc. 

d.  A12  and  remaining  predicate  of  A13: 

these  predicates  are  just  a restatement  of  antecedents. 

8.  Path  A12-1S  to  All  (return  to  start  of  loop) 

The  verification  condition  is: 

A12  a A13  ix:-ix+l;  bp:*bp+l  (All) 

The  verification  condition  as  expressed  above  is  rewritten  as 
follows,  replacing  ix  and  bp  by  ix+1  and  bp+1  in  assertion  All 
(as  the  assignment  rule  of  inference  requires): 

A12  a A13  ^ 

[0<*bp+l<*it  a 0<*ix<»A  A (ix-bp-1) rem80-0  a 2<*Jl<*256 
^ ca*ix  a «.t»80  a n>»l  a n» ( (t-1) div80) +1 
a cb*string  of  next  80  or  fewer  characters] 

The  verification  condition  is  once  more  proved  by  considering 
the  consequents  one  at  a time. 

a.  0<*bp+l<*At: 

0<*bp  0<»bp+l;  and  since  only  integer  arithmetic  is  permitted, 

bp<tt  -=^bp+l<»tt. 

b . the  remainder  of  the  consequents : 
restatements  of  predicates  of  A12  and  A13. 

9.  Path  All  to  A14 

The  verification  condition  is: 

All  a -»(ix<*£  a bp<£t)  A14 

The  proof  is  constructed  by  showing  the  consequents  of  the  veri- 
fication condition  one  at  a time. 


a.  [(bp*80  a (jx-l)rem80»0)  \/  ix-l»4] : 

—i  (ix<»4  /n  bp<it)  means  that  either  ix>£  or  bp>»fct,  or  both. 

Consider  ix>i  as  case  1; 

ix>Z  a 0<-ix-l<»4  -=£>■  4<ix<»4+l, 

so  ix»4+l  and  ix-l»fc  , in  which  case  the  consequent  is  true. 
Consider  bp>«it  as  case  2; 
bp>«£t  A 0<«bp<"tt  =$►  bp*tt; 

At»80  a bp-tt  »^bp»80; 

bp«80  •»»  (ix-l-bp)  rem80»(ix-I)rem80 ; 

since  (ix-l-bp) rem80-0 , then (ix-1) rem80»80 , 

and  the  consequent  is  true. 

So  in  either  case  the  disjunctive  consequent  holds. 

b.  the  remainder  of  the  predicates: 

these  predicates  are  just  a restatement  of  antecedents. 

10.  Path  A6-10  to  A14 

The  verification  condition  is: 

{ A6  * A7  /\  A8aA«3aA10}  F;  while  C do  P {A14}  , 
where  F represents  the  statements  between  A6-10  and  the  while 
statement,  C represents  the  predicate  of  the  while  statement 
and  P is  the  while  loop  body.  The  previous  proofs  of  the 
verification  conditions  for  paths  A6-10  to  All,  All  to  A12-13, 
A12-13  to  All,  and  All  to  A14  satisfy  the  requirements  of  the 
rule  of  inference  for  while  statements,  and  therefore  the 
verification  condition  for  path  A6-10  to  A14  is  proven. 

11.  Path  A14  to  A6-10 

The  verification  condition  after  substituting  c+1  for 
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c in  assertions  A6-A9  (as  required  by  assignment  rule  applicable 
to  "for  c:*l  step  1_"  which  increments  c)  is: 

A14  [ ( (ix-1)  rem80»0  =$>  c+l*((ix-l)div80)+l) 

a 0<»ix-l<*i  /v  (ix-l<4  ^ c+l<*n) 

A -i  ((ix-l)rem80*0)  ■=$>  c+1-  ( (ix-1) div80)  +2 
A (ix~l»i  -=^  c+l>n)  a ((ix-l)rem80=0  v ix-l*i)  a A10] 

The  proof  of  the  verification  condition  is  shown  for  each  con- 
sequent. 

a.  A10  a 0<»ix-l<*i  a ( (ix-l)rem80*0  v ix-l*&) : 
these  predicates  are  just  a restatement  of  antecedents. 

b.  (ix-l)rem80»0  =$>  c+l= ( (ix-1) div80) +1 : 

In  addition  to  being  a counter  for  the  for  loop,  "c"  is  a 
count  of  the  number  of  data  cards  that  have  been  read,  because 
there  is  exactly  one  readcard  statement  in  the  for  loop  body. 
ca»ix-l  is  the  number  of  characters  that  have  been  assigned 
from  the  buffer  into  the  array  "text";  each  time  the  loop  is 
executed,  80  characters  are  assigned  into  "text",  except 
that  the  last  time  the  loop  is  executed,  from  1 to  80  characters 
may  be  assigned. 

If  (ix-l)rem80»0 , an  even  multiple  (namely  (ix-l)div80)  of  80 
characters  have  been  assigned,  and  loop  has  been  executed  that 
number  of  times  as  control  returns  to  A6-10;  thus,  c+1  (the 
new  value  after  the  step)  is  then  one  more  than  that  number,  or 
c+l*((ix-l)div80)+l.  Therefore  the  consequent  holds. 

c.  —<  ((ix-1)  rem80«0)  =*>  c+l*((ix-l)div80)  +2  : 

The  proof  for  this  consequent  is  similar  to  the  preceding,  ex- 
cept that  because  (ix-1) rem80  is  not  equal  to  zero,  less  than 


80  characters  have  been  read  when  control  returns  to  A6-10,  and 
the  loop  has  been  executed  one  time  more  than  in  the  case  above. 
Thus,  c+l*( (ix-l)div80)+2 ; q.e.d. 

d.  ix-l<t  =$>  c+l<*n: 

If  ix-l<i,  then  since 

(ix-l*i  n/  (ix-1) rem80*0)  (proved  above), 

it  must  be  that  (ix-l)rem80*0 . 

Therefore,  from  the  above  proved  conditional, 

c+l= ((ix-l)div80+l  is  true, 

and  ix-l<t  ix-l<*£-l, 

so  c+l<* ( (A -I) div80) +1. 

Then  because  ( (£-l)div80) +l*n,  c+l<=n. 

e.  ix-l*£  =^>c+l>n: 

There  are  two  possibilities. 

First,  assume  — t( (ix-1) rem80»0 . 

Then  c+l*( (ix-l)div80) +2 , 

and  c+l>( (ix-l)div80) +1. 

If  ix-l*4,  then  ix-l>t-l  and 

U-l)div80  *(ix-l)div80 ; 

therefore  c+l>( (t-1) div80) +1 , thus  c+l>n. 

Second,  assume  (ix-1) rem80*0 . 

Then  c+l«((ix-l)div80)+l, 

and  since  £*ix-l,  t rem  80*0 

and  (ft-l)div80<&  div  80. 

Therefore  c+l> ( (t-l)div80) +1 , thus  c+l>n. 

In  either  case,  c+l>n  and  the  consequent  is  proved. 
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12.  Path  A6-10  to  A15 


The  verification  condition  is: 

A6  a A7  a A8  a A9  a A10  A c>n  -=£> 
ix-l*A  a ca*t  a 2<»Jt<*256  A it*80 
2<-£<»256  and  Jlt=80  are  restatements  of  predicates  contained 
in  the  antecedent  of  the  verification  condition;  the  remaining 
two  predicates  are  verified  as  follows: 

a.  ix-l*i: 

ix-l<2.  =?>  c<»n  is  true  (an  antecedent),  so  the  contrapositive 
is  also  true: 
c>n  (ix-1) >*£. 

Since  c>n,  ix-l>»i. 

Also,  0<*ix-l<-£  (an  antecedent),  therefore  ix-l*Jl 

b.  ca=Jl: 

ca-ix-1  A ix-l=i  ca=£ . 

13.  Path  A5  to  A15 

The  verification  condition  is: 

AS  for  statement  {A15}. 

The  previous  proofs  of  the  verification  conditions  for  paths 
AS  to  A6-10,  A6-10  to  A14,  A14  to  A6-10,  and  A6-10  to  A1S  satis- 
fy the  requirements  of  the  for  rule;  therefore  the  verification 
condition  for  this  path  is  proved. 

14.  Input  Assertion  to  Output  Assertion 

The  proof  of  partial  correctness  for  this  procedure 
is  completed  by  concatenation  of  paths  A4  to  A5  and  A5  to  A15. 
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15.  Termination 


During  the  preceding  proof  of  partial  correctness,  the 
reader  should  have  been  convinced  that  the  procedure  terminates 
by  the  relations  among  ix-1,  c,  and  n,  and  by  those  among  ix, 

Z,  bp,  and  it.  If  not,  termination  is  assured  because  the  program 
has  one  entry  and  one  exit  and  is  a concatenation  of  assignment 
statements  and  a for  statement.  The  for  statement  terminates 
if  its  loop  body  terminates;  in  this  case,  the  body  terminates 
provided  the  while  loop  eventually  terminates. 

The  formality  of  well-ordering  could  be  applied  to  show  the 
termination  of  the  while  statement;  however,  termination  is 
evident  since  "It”  is  fixed  at  80  and  "bp"  starts  from  0 and  is 
incremented  by  one  on  each  execution  of  the  loop  body  (which 
terminates  as  it  has  no  loops) . Thus  "bp"  must  eventually  exceed 
"Jit"  and  the  while  statement  must  terminate  (it  may  terminate 
earlier  if  ix*Jl) . 

H.  PROCEDURE  PALINDROME-*- CHECK 

Figure  5 contains  the  assertions  for  this  procedure. 

1.  Input  Assertion:  A17. 

2.  Output  Assertion:  A27-29. 

3.  Intermediate  Assertions: 

A18  through  A26.  Verification  conditions  are  provided 
for  all  possible  assertion- to-assertion  paths  in  the  following 
paragraphs . 

4.  Path  A17  to  A18-22 

The  verification  condition  is: 
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procedure  pa  1 Ind roue —check.; 

coannt  find  all  palindrome*  within  clean  text  a trine; 
becln 

( 2<*  1<*2S6  A ca*l  A jx«l  3 

comment  acan  text  from  left  to  rlchtt 
for  1x5*2  a tap  1 

' 

t 2<  * 1<  *286  A ca*  1a  jx>  ® A 2<  * lx<  * 1+ 1 3 
C VxC  ( 2<  *x<  * lx-  1 a text  <x-l)*  text  C x)  ) 

3y<r<J*  a l<*bop(y><*x-l  a x<*eop(  y)<*  1)  3 3 
C Vx£  ( 3<  *x<  * lx— 1 a text(x-2)*text(x>)-^ 

3y(y<jx  a 1<  *bop(  y)  < *x~2  a x<  *eop(  y)<  * 1)  ] 3 
£ Yy£  ( 6<  y<  jx  a bop(y)>l  a 6<eop<  y)<  1) 

~(  text  ( bop(  y)  — 1 ) * text! eop(  y)  + l> ) 3 3 
C Vyf  <«<y<  jx  a ~<eop(y)=«)  ) =*> 

Catr  ln*<bop(y)  ,eop(y)  )*ok  a bop(y)>»l  A eop(y)<*l 
a Vx(  (6<z<jx  a ~(x»y))-^  _ 

( ~(  bop(  z)  =bop(  y) ) a ( bop(  zX  bop(  y)  ^ «op(*X«op(y)))  )i  J J 

until  lenctb— ^ of— text  do 
becln 

If  text(  lx-13  = text(  lx)  then  cont  inue-checktng(  ( lx- 1 ) ■ lx)  ; 

£ 2<  * 1< *286  a ca* 1 a jx>6  a 2<* 1x< “ 1 a A20  a A2 1 A A22  3 
£ Vy£(2<*x<*lx  a text(x-l)*text(x))=^> 

3y<y<jx  a 1<  *bop(  yX  *x— 1 a x<  *eop(  yX  * 1)  3 3 

If  lx  ~*  2 then 

If  text( lx— 2)*text(  lx)  then  cont lnue_checklnc< < lx-2) . ix) ; 

C A23  A A26  A A21  a A22  3 
C Vx£  ( 3<  *x<  * lx  A text(x-23*  text(x) 

3y<y<jxA  l<*bop(yX*x-2  a x<  =eop(  yX  * 1 ) 3 3 

end; 

£ 2< * 1< *286  a ea* 1 A j*>«  a A21  a A22  3 
C Vx£(2<*x<*l  a text(rl)*text(x) ) — P 

3y(y<JXA  1<  *bop(  y)  < *x—  1 A x<  *eop(  yX  * 1 ) 3 3 
C VxC  ( 3<  * x<  * 1 a text  ( x-2)  * text(  x) ) -=^> 

3y<y<J*  a l<*bop<y)<=x-2  A x<  =eop(  y)  < = 1 ) 3 3 

end  pal indroam— check; 


FIGURE  5 


PROCEDURE  PALINDROME*- CHECK 
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A17  a ix-2  ^A18  a A19  a A20  a a21  a A22 
Proof  is  shown  by  considering  the  consequents  one  at  a time. 

a.  2<»A<*256  a ca*&  {from  A18}: 

These  two  predicates  are  a restatement  of  part  of  the  input 
assertion.  Their  truth  is  not  modified  in  this  procedure,  and 
they  are  repeated  in  all  intermediate  assertions.  They  will 
not  be  discussed  in  the  discussion  of  the  remaining  verification 
conditions  for  this  procedure. 

b.  jx>0  (from  A18): 
jx»l  jx>0. 

c.  2<*ix<*A+l  (from  A18h 

(ix»2  a 2<=Jl)  2<»ix<*A+l. 

d.  A19 : 

No  x can  satisfy  the  antecedent  2<=x<=ix-l  because  ix-l=l; 
therefore  the  conditional  is  true. 

e.  A20: 

This  consequent  is  similarly  true. 

f.  A21 : 

No  integer  y can  satisfy  the  antecedent  0<y<jx  because  jx*l; 
therefore  the  conditional  is  true. 

g.  A22: 

Similarly. 

5.  Path  A18-22  to  A27-29 

The  verification  condition  is: 

A18  a A19  a A20  /v  A21  a A22  A ix>i  -=$>A27  a A28  a A29 
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The  consequents  are  all  restatements  of  the  antecedents  except 
A28  and  A29;  proofs  of  their  validity  follow: 

a.  A28: 

ix<*l  +1  a ix>&  =4>  ix-l=£. 

Therefore  assertion  A28  is  a restatement  of  A19  with  l replacing 
ix-1  in  the  first  predicate  of  the  antecedent,  and  the  assertion 
holds. 

b.  A29: 

This  assertion  holds  similarly. 

6.  Path  A18-22  to  A23-24,  Case  1 

Case  1 for  this  path  is  arrival  of  control  at  assertions 
A23-24  after  execution  of  the  if  statement  with  true  predicates. 
In  this  case,  the  verification  condition  is: 

A18  /v  A19  a A20  ^ A21  a A22  a 

ix<s!l  a text(ix-l)=text(ix)  =£?  A23  a A24 
The  following  condition,  deducible  from  the  antecedents  of  the 
verification  condition,  becomes  the  input  assertion  to  procedure 
"continue-<-che  eking"  whenever  the  actual  parameters  "ix-1"  and 
"ix"  are  replaced  by  the  formal  parameters  "first"  and  "last": 

2<=«,<  = 256  A ca=Jl  A jx>0  a l<*ix-l<*H-l  a 2<*ix<  = il 
A ix-l<ix  a text (ix-1) =text(ix)  a A21  a A22 
The  output  specification  of  the  procedure  "continued-checking," 
after  replacing  "current"  by  the  value  "current"  was  assigned 
at  the  procedure  call  in  the  proof  of  correctness  of  that  pro- 
cedure, namely  the  value  "ix",  is: 
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A21  a A22  a 2<*4  <*256  a ca»£  A jx>0  a 
3y(y<jx  a l<-bop(y)<»ix-l  a ix<*eop(y)<»£) 

Given  that  the  procedure  "continue*- checking"  has  been  proven 
correct  (presented  in  the  next  section  of  this  appendix) , all 
requirements  for  the  rule  of  inference  for  procedure  calls  have 
been  satisfied,  and  the  output  assertion  of  " cont inue*- che eking ," 
as  rewritten  above,  can  be  used  to  show  the  truth  of  assertions 
A23-24.  In  fact,  assertion  A23  is  entirely  a restatement  of 
either  this  output  assertion  or  the  antecedents  of  the  verifi- 
cation condition.  Assertion  19  ensures  the  validity  of  assertion 
A24  over  the  range  of  x from  2 to  ix-1; 

(text(ix-l)=text(ix)  (an  antecedent) 

and  ^y(y<jx  a l<*bop(y)<*ix-l  A ix<=eop(y )<=£.) 

(from  the  output  assertion  of  "continue  checking")  together 
extend  the  range  of  x to  ix,  and  therefore  assertion  A24  holds. 
Thus  the  verification  condition  for  this  case  has  been  proved. 

7.  Path  A18-22  to  A23-24,  Case  2 

Case  2 is  the  case  when  the  if  statement  preceding 
A23-24  is  executed  with  the  predicates  false;  in  this  case,  the 
verification  condition  is: 

A18  A A19  a A20  a A21  A A22  A 
ix<-t  A (text  (ix-1) -text  (ix) ) =y>A23  a A24 
All  of  the  consequents  but  A24  are  a restatement  of  antecedents; 
A24  is  a restatement  of  A19  with  the  range  of  x increased  to 
include  x*ix,  the  ix-th  value  having  been  checked  for  compliance 
with  the  assertion  in  the  current  iteration  of  the  for  loop. 


108 


Since  the  antecedent  of  the  conditional  contained  in  assertion 
A24  is  false  in  this  case  for  x-ix,  the  conditional  is  true  for 
x-ix,  and  assertion  A24  holds.  Thus  the  verification  condition 
is  proved. 

8.  Path  A23-24  to  A25-26,  Case  1 
This  first  case  occurs  whenever  ix*2,  or 

when  “■»  (ix-2)  and  also  — »■  (text  (ix-2)-text (ix) ) ; 
in  this  case,  no  call  is  made  to  procedure  ’'continued-checking" , 
and  the  verification  condition  is: 

A23  a A24  A2S  a A26 

Assertion  A25  is  a restatement  of  antecedents,  and  assertion  A26 
is  just  assertion  A20  with  the  range  of  x extended  to  include 
x-ix.  The  conditions  for  this  case  ensure  that  for  x-ix  the 
antecedent  of  the  conditional  contained  in  A26  is  false;  either 

ix- 2  and  3<*x  is  false  or 

-i  (text (ix-2)-text(ix) ) . Therefore  the  conditional  is  true  for 

x- ix  and  thus  assertion  A26  holds;  the  verification  condition 
is  proved.  ' 

9.  Path  A23-24  to  A25-26,  Case  2 
In  this  case  the  call  to  "continued-checking"  is  executed, 

and  the  verification  condition  is: 

A23  A A24  A -»(ix-2)  a text (ix-2) -text (ix) 

A25  A A26 

- Similarly  to  the  proof  for  the  previous  path  containing  a call 
to  procedure  "continuedchecking",  it  may  be  shown  that  the 
antecedents  of  the  verification  condition  satisfy  the  procedure's 
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input  assertion  and  that  the  output  assertion,  together  with 

the  antecedents,  satisfy  assertions  A25-26.  In  assertion  A26 

■ 

the  range  for  the  universal  quantifier  x is  extended  to  include 
the  case  x*ix  as  before. 

iO.  Path  A25-26  to  A18-22 

The  verification  condition  is  (substituting  ix+1  for 
ix  in  A18-20  because  of  the  assignment) ; 

A2S  a A26  =£>  A21  ^ A22  a 
2<*t<*256  a ca»t  a jx>0  a 2<*ix+l<»£+l 
a Vx[(2<ax<*ix  a text  (x-1) “text (x))  •=>> 

^y(y<jx  a l<*bop(y)<»x-l  a x<*eop(y)<*Jl)  ] 
a ^x[(3<“x<“ix  a text(x-2)»text(x)) 

3y(y<jx  a l<=bop(y)<*x-2  /\  x<aeop(y)<*s,)  ] 

All  of  the  consequents  but  2<*ix<“ji+l  are  restatements  of 
antecedents ; 

and  2<*ix<=2,  ^ 3<*ix+l<“£+l , thus  2<*ix+l<=>Jl+l  is  true  and 
the  verification  condition  is  proved. 

H . Path  A17  to  A27-29 

The  verification  condition  is: 

{A17}  for  statement  {A27-29} 

The  previous  proofs  of  the  verification  conditions  for  paths 
A17  to  A18-22,  A18-22  to  A23-24  to  A25-26,  A25-26  to  A18-22, 
and  A18-22  to  A27-29  satisfy  the  requirements  of  the  for  rule; 
therefore  the  verification  condition  for  this  path  is  proved, 
thus  completing  the  proof  of  partial  correctness  for  this 
procedure. 
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12.  Termination 


The  procedure  has  one  entry  and  one  exit,  and  the  only 
loop  is  a for  statement,  which  have  been  shown  to  terminate. 
Therefore  the  procedure  terminates. 

I.  PROCEDURE  CONTINUED-CHECKING 

Figure  6 contains  the  assertions  for  this  procedure.  A 
constant  "current"  is  introduced  in  the  proof  and  the  assertions; 
this  constant  is  given  the  value  of  "last"  at  the  time  of  the 
procedure  call. 

1.  Input  Assertion:  A30-32. 

2.  Output  Assertion:  A38. 

3.  Intermediate  Assertions: 

A33  through  A37.  Verification  conditions  are  provided 
for  all  possible  assertion-to-assertion  paths  in  the  following 
paragraphs . 

4.  Path  A30-32  to  A53 

The  verification  condition  is: 

A30  A A31  A A32  A p»true  A33 
The  consequent  is  a restatement  of  the  antecedents  with  the 
addition  of  the  predicate  "current-last,"  as  mentioned  above. 

Thus  proof  of  the  verification  condition  is  immediate. 

5;  Path  A33  to  A34 

The  terminology  "string (first , last) -ok"  used  in  these 
assertions  indicates  that  the  substring  from  text (first)  to 
text (last)  is  a valid  palindrome.  The  verification  condition 
for  this  path  is: 
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procedure  coat  lnue_cbecklng  (Integer  value  first,  laet)i 
eoaeil  Given  flret  and  last  as  pointers  to  a pnl indrone 

of  alas  2 or  3,  this  procedure  cheeks  whether  or  aot  this 
palladrona  Is  Included  la  a larger  pallndronet 

keg  la 

( 2<  ■ 1<  *286  A ca"  1 A jx>#  A 1< 9 first!  » 1-1  A 2<  * las *<  « l A f Ire  t<  last 
a text ( f Irs t ) 9 text ( tsst)  ) 

C VTC<8<T<JX  a kop(  y)  > 1 a 8< eop<  y> < 1 > 

~(  text < bop<  y) - 1 ) • text ( eop<  y)  + 1 > ) 1 ) 

t Vrl  < •<  T<  J*  A ~<eop<T>*8)>"^ 

[ s tr  lag<  kop<  y)  ,eop(  y) ) *ok  a bop(y)>*l  a eop(y)<«l 
a Vul  ( •<  a<  Jx  A •'(I'jr))  ^ 

( *»<  kop(x)  9 bop!  y)  > a ( bop<  a)  < bop<  y)  eop<  x)  < eop<  y>  > ) >1  1 


logical  pa  1 indrone I 
pa  1 Indrone s * true  t 

( A3t  A A31  a A32  a p« true  A current 


<(flrst>l>  and  ( las t< length— of— text)  e 
begla 

If  text! f lrst-1)  * text! las t+ 1)  then 

begin 

consent  larger  pnllndrone  found; 
f lrstsef irst-lt 
lasts  s las t+1 1 


( AM  A A31  A A32  a current<  * last  A string!  first,  last  >*ok 
a ( first9 1 v last9 1 v text! f lrst-1) 9 text( las t+ 1 ) ) ) ) 


record— pa  1 Indrone! first,  last) t 
( A3I  A A32  A 2!M!«236  A ea9 1 A jx>«  ) 

a ^t<  T<  J*  a 1<  9bop(  y)  <9curreat- 1 A current!  9eop!  y)  < 9 1 ) ) 
end  cont lane -chocking! 


FIGURE  6 


PROCEDURE  CONTINUE  ■►CHECKING 


I 


A3 3 ^ A34 

The  consequents  are  considered  one  at  a time. 

a.  A30  a A31  a A32 : 

these  predicates  are  just  a restatement  of  antecedents. 

b.  current<-last : 
follows  directly  from  current-last. 

c.  string(first,last)-ok: 

static  analysis  of  the  program  showed  that,  for  all  calls  to 
this  procedure,  either  first-last-1  or  first-last-2  (this 
could  have  been  a predicate  of  the  input  assertion) , and  this 
fact  and  text(first)-text(last)  ensures  that  string(first ,last) 
is  a palindrome  when  control  reaches  assertion  A34  from  A33. 

d.  p-false  -» (text(first-l)*text(last+l) : 

since  p-true,  the  conditional  is  true  regardless  of  the  truth 
of  the  consequent. 


6.  Path  A34  to  A35 

If  program  control  reaches  assertion  A3S,  then  the 
predicates  of  the  while  and  i£  statements  are  true  and  the 
verification  condition  for  this  path  is  (substituting  first-1 
and  last+1  for  first  and  last  in  the  consequent,  due  to  the 


assignment  statements) : 

A34  a first>l  a last<«,  a p-true 
a text(first-l)«text(last+l)  •=%? 

2<-t<-256  a ca-A  a jx>0  a l<-first-l<»!-l  a 2<-last+l<»t 
a first-l<last+l  a text(first-l)-text(last+l)  a A31  a A32 
a current <- last+1  a string(first-l,last+l)-ok 


mr- 
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The  consequents  of  this  verification  condition  are  considered 
one  at  a time. 

a.  2<*A<»256  a ca»£  a jx>0: 

these  predicates  are  just  a restatement  of  antecedents;  they 
remain  valid  throughout  this  procedure  and  will  not  be  discussed 
during  the  proof  of  further  verification  conditions. 

b.  l<»first-l<*i-l : 

l<=first<»£-l  A first>l  =%>  1<=  firs t-l<»i-l. 

c.  2<»last+l<®Jl : 

2<  = last<s*£  a last<£  2<*last+l<=£ . 

d.  first-l<last+l : 
follows  directly  from  first<last. 

e.  text(first-l)»text(last+l)  a A31  a A32: 
these  predicates  are  just  a restatement  of  antecedents. 

f.  current<=las t+1 : 
follows  directly  from  current<*last . 

g.  string(first-l ,las t+1) =ok: 
string(first ,last)*ok  A text(first-l)=text(last+l) 
s=$>  stringCfirst-1  ,last+l)  =ok. 

This  concludes  the  proof  of  verification  condition. 

7.  Path  A34  to  A36 

If  control  reaches  assertion  A36  from  A34,  then  the 
predicate  of  the  while  statement  is  true,  that  of  the  if^  state- 
ment false,  and  the  verification  condition  is: 

A34  a first>l  A last<! 

a -«(text(first-l)*text(last+l))  a p*false  -$>A34 
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The  consequents  are  shown  one  at  a time. 


a.  p»false  =£>  -i(text(first-l)=text(last+l))  : 

the  antecedent  and  consequent  of  this  conditional  are  both  true 
(antecedents  of  the  verification  condition);  therefore,  the 
conditional  is  true. 

b.  the  remainder  of  the  consequents: 

these  predicates  are  just  a restatement  of  antecedents. 

8.  Paths  A35  to  A34  and  A36  to  A34 
Since  A35  and  A36  are  each  identical  to  A34  and  since 

there  are  no  program  statements  on  these  paths,  the  verification 
condition  is  A34  A34 , which  must  be  true. 

9.  Path  A34  to  A37 

The  verification  condition  is: 

A34  A ~'(first>‘l  a last<£  a p*true)  A37 
The  consequents  are  considered  one  at  a time, 
a.  [first*l  v last»Jl 
V (text (first -1)  =text (last+1) ) ] : 
from  the  antecedent  —i  (first>l  a last<£  a p=true) , 

DeMorgan'  Rule  gives: 
first<=l  ^ last>a£  V p*false. 

Since  also  first>*A  and  last<*H  , and 

since  p*false  (text(first-l)*text(last+l) , 

the  above  is  equivalent  to: 

first*l  v'  last*#-  v -n  (text(first-l)*text(last+l)) ; 
thus  the  consequent  is  shown. . 
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b.  the  remainder  of  the  consequents: 
these  predicates  are  just  a restatement  of  antecedents. 


10.  Path  A33  to  A37 

The  verification  condition  is: 

{A33}  while  statement  {A37} 

The  previous  proofs  of  the  verification  conditions  for  paths 

A33  to  A34,  A34  to  A35,  A34  to  A36 , A3S  to  A34,  A36  to  A34, 

and  A34  to  A37  are  sufficient  to  show  this  verification  condition. 

11.  Path  A37  to  A38 

Assertion  A37  satisfies  the  input  assertion  to  proce- 
dure "record+palindrome"  (in  this  case  the  names  first,  last 
and  current  retain  the  same  connotations) . Assertion  A38  is 
precisely  the  output  assertion  of  "record«-pal  indrome ."  Therefore 
the  verification  condition  for  path  A37  to  A38  is  verified  by 
the  proof  of  correctness  for  the  called  procedure  (in  the  next 
section) . 

12 . Input  Assertion  to  Output  Assertion 

The  proof  of  partial  correctness  for  this  procedure 
is  completed  by  concatenation  of  paths  A30-32  to  A33,  A33  to 
A37,  and  A37  to  A38. 

13.  Termination 

Procedure  "continue-*-checking"  has  one  entry,  one  exit, 
and  but  one  loop,  the  while  statement.  Assuming  "record-*-pal in- 
drome"  terminates  (proven  elsewhere) , this  procedure  terminates 
if  the  loop  terminates.  Clearly  the  loop  body  terminates,  so 
loop  execution  will  terminate  if  one  of  the  three  conditions: 
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first>l,  last<*  , or  p-true 

ever  takes  on  a value  of  false.  Since  initially  first>-l  and 
"first"  is  decremented  by  1 on  each  loop  iteration  for  which  "p” 
is  not  set  equal  to  false  (in  which  case  termination  would  be 
assured),  then  the  well-ordering  principle  of -the  natural  numbers 
requires  eventually  first<»l  (unless  the  loop  terminates  sooner). 
So  the  procedure  terminates. 

J.  PROCEDURE  RECORD^ PAL  INDROME 

Figure  7 contains  the  assertions  for  this  procedure. 

1.  Input  Assertion:  A39-41. 

2.  Output  Assertion:  A51-S2. 

3.  Intermediate  Assertions: 

A43  through  A48.  Verification  conditions  are  provided 
for  all  possible  assertion- to-assertion  paths  in  the  following 
paragraphs . 

4.  Path  A39-41  to  A42-44 

The  verification  condition  is  (substituting  1 for  i 
in  assertions  A42  and  A44  because  of  the  assignment  to  the 
for  loop  counter) : 

A39  a A40  a A41  a entry-true  =£> 

A39  a A40  A A41  a l<»jx  A A43  A 
[ (entry-true  a -»  (eop(O) -0) ) Vz[0<z<j^s> 

( — i(bop(z)»first)  A (bop(z)<first  eop (z) <last) ) ] ] 

The  consequents  are  considered  one  at  a time, 
a.  A39  A A40  A A41 : 

these  predicates  are  just  a restatement  of  antecedents. 


b.  l<-jx: 

follows  directly  from  jx>0. 

c.  A43: 


since  entry-true,  the  antecedent  of  the  conditional  is  false 
and  the  conditional  is  true. 

d.  the  remaining  complex  predicate: 
since  there  is  no  integar  z satisfying  0<z<i,  the  consequent 
of  the  antecedent  of  this  predicate  is  true,  and  the  conditional 
is  shown;  thus,  the  final  consequent  of  the  verification  con- 
dition is  proved. 

5.  Path  A42-44  to  A4S-46 

In  the  event  control  passes  to  assertion  A45-46  from 
A42-44,  the  predicate  of  the  intervening  if.  statement  is  true 
and  the  verification  condition  is: 

A42  A A43  a A44  a i<=jx-l  A f irst>=bop (i) 
a last<=eop(i)  a entry  -false  =>A45  a A46 
Proof  is  by  considering  the  consequents  one  at  a time. 

a.  A39  a A40  A A41  (from  A45>: 

these  predicates  are  just  a restatement  of  antecedents. 

b.  i<-jx-l  (from  A45): 

this  predicate  is  a restatement  of  the  antecedent  resulting  from 
the  test  on  the  loop  counter. 

c.  entry-false  =.  3y(y<-jx  a l<-bop(y) <»current-l 

a current<*eop (y) <*i)  (A43): 

entry-false  is  true;  thus  it  must  be  shown  that  there  exists 
a value  for  y such  that  the  predicates  following  the  "existential" 
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procedar*  r*cord_pe 1 indrome  (Integer  value  f Ire t,  last); 
const  Record  only  mz  loaf  th  pa  1 Indronoo . Fla®  previously 

recorded  palindromes  If  they  are  Included  in  the  palindrome 
specified  by  first  and  last. 

jx  was  Initialized  to  1.  After  completion  jx  points  to  the 
next  entry  in  be® in— of_pa 1 indrome  and  end-of-pa I indr o me ; 

be®  in 

C 2<  * l<«2Sd  A ca«  I A jx>9  A l<  afire  t<  ■ 1-1  a 2<  3 las  t<  * 1 A f Ira  t<  last 
A oarrent< « last  A atrln®<  first, laat)*ok 

A(flrat»l  V lut'l  v“  *•<  taxt<  firs  t-l)»  text!  las  t+1)  ) ) 0 
CVyt(«<y<JxA  bop(  y)  > 1 A »<eop(  y)<  1)**0 

~(  text <bop(y)-l)»  text (eopCyl  + l)  ) 1 ) 

C Vyt  (#<y<jx  A ~<*op(y>  ■•>>»*> 

Cs  trln®<bop(y)  ,eop(  y))«ok  a bop(y)>«l  a eop(y)<*l 
a Vz(  (*<a<jx  A~(z*y))^ 

( ~<  bop(x) *bop(  y)  ) A ( bop( z)< bop(y)  =— $ eop(  z)  <eop(  y)  ) ) )1  1 J 

inte®er  It  commnt  local  counter; 

lo®lca 1 entry; 
entry;* true; 
for  i:»l  step  1 

( A39  a A40  a A41  a i<*jx  ) 

C entryefalae  =^3y(y<=jx  A l<*bop(y><*current-l  a current< -*op<  y)<  - 1 ) ) 

( (entry* true  a ~(oop( 1*1)*#)) 

Va£(Kz<l  (~(bop(z)*f  lrst)  a ( bop(  z)<  f Ira  t ecp(  z)<  las  t > ) 1 ) 

until  JX- 1 do 
be®ln 

if  < ( f irs t>*be® in— of— pa  1 lndrome( i) ) 

and  ( laat<*end_of_pallndrome(  1)))  then 
be®in 

comment  Palindrome  la  entirely  Included  in  a previously 
recorded  palindrome.  No  entry  required' 
entry: ■ fa lse  t 

( A39  a A40  a A41  a K3jx-l  A A43  ) 

{ (entry*  true  A «•(  eop(  1)  =9) ) 

V*£(Kz<  * 1 ( ~(  bop(z)  *f  lrat)  A.  ( bop(  z)  < f irs  t *op(z)<last))l  ) 


be®ln 

if  ( (begin— of— pa  1 lndrome(  1)  >*  first) 

and  ( end— of— pa  1 lndrome( 1 ) <s  last))  then 
begin 

end— of— pal indrome( 1) :*0; 
comment  fla®  smaller  palindrome; 
end  t 

( A45  a A46  ) 


{ A4B  A A46  J 


comment  All  previously  recorded  palindromes 
compared  with  last  Input; 


FIGURE  7 


Page  1 of  2 
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A49:  t A39  a A4«  /\  A41  a A43  3 

AS 9:  C (•■try*  true  A ~<eop<  jx»«9)  ) 

VzC  9<  *<  ju  "4»(~<b0p(*)»f  lr*t)  a (bop(i)<f  lr»t  =4  sop(z><  } 

if  entry  » true  then 
k«(ia 

coatnt  larger  than  all  prevloue  or  overlapping  or  diajolnts 

begln_of— pal indroae( jz) : * f ire  t j 

end-of-pa 1 lndrone( jx)i* last; 

jz* “jx+ 1 « 

end  i 

AS  1 : C A49  A A41  A 2<=»1<*256  /v  ca>  1 A ju>9  ) 

A82:  t A 1< *bop< y) < “current- 1 a cnrrent<  *eop(  y)<  * 1 ) 3 

end  record—pa 1 Indrone t 


FIGURE  7 
Page  2 of  2 
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quantifier  hold. 

It  is  proposed  that  y=i  will  satisfy  those  conditions. 

Since  i<*jx-l,  i<jx  holds. 
i<jx  a A41  •=&  bop(i)>=l; 

current<*last  a first<last  =#>  current-l<=f irst ; 
current-l<*first  a bop (i) <afirst  =>  bop (i) <=current-l ; 
therefore  l<=bop(i)<scurrent-l  holds. 
current<=last  a last<=eop(i)  =£>  current<=eopCi) ; 
i<jx  a.  A41  ^ eop(i)<3H; 
so  current<=eop(i) <=l  holds. 

Therefore,  the  necessary  predicates  are  all  true  when  y is 
chosen  equal  to  i;  this  consequent  of  the  verification  condition 
is  proved. 

d.  A46: 

since  entry=false  is  an  antecedent  of  the  verification  condition, 
entry=true  is  false  and  the  conditional  which  is  assertion  A46 
is  true . 
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6 . Path  A42-44  to  A47,  Case  1 

Control  can  pass  to  assertion  A47  from  A42-44  either  by 
executing  the  compound  statement  with  the  comment  "flag  smaller 
palindrome"  or  by  failing  to  execute  that  compound  statement 
when  the  predicate  of  the  preceding  i^f  is  false.  For  case  1, 
the  case  where  the  predicate  is  false,  the  verification  condition 
is : 

A42  A A43  a A44  A i<*jx-l  A 
-1  (first>*bop(i)  a last<s*eop(i) ) a 
-^(bop (i)  >-first  a eop(i)  <=last) 


I 
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— > A47 

All  of  the  consequents  contained  in  A47-  A45  a {A46  } except 
A46  are  restatements  of  the  antecedents. 

a.  (entry-true  * *“'  (eop(i)-O))  as> 

Vz[0<z<»i  ( — i(bop(z)-first)  a 

(bop(z) <first  =3>  eop(z)<last))  ] {A46}  : 

If  entry-false,  the  conditional  is  true  without  further  proof. 

If  entry-true  a -» (eop(i) *0)  , the  antecedent  of  the  verification 
condition  provides  that  the  generalization  on  z is  true  for 
0<z<i;  if  it  is  shown  to  hold  for  z«i,  then  it  is  true  for 
0<z<*i  and  this  consequent  of  the  verification  condition  is 
proved. 

Either  bop(i)=first  or  bop(i) <first. 

Suppose  bop(i) -first ; 

then  either  eop(i)<-last  or  last<-eop(i) , 
and  then  one  of  first>»bop(i)  a last<*eop(i) , 
or  bop(i)>=first  a eop (i) <*last , must  be  true. 

But  the  antecedent  of  this  verification 
condition  indicates  both  are  false; 
therefore  —i  (bop (i) -first . 

Now  suppose  bop(i)<first; 

then  first>*bop(i)  is  true,  and 

from  •—'(first>*bop(i)  A last<-eop(i) ) , 

it  is  shown  that  last<-eop(i)  must  be  false. 

Thus  bop(i)<first  eop(i) <last , and 
the  generalization  on  z holds  for  0<z<-i; 
therefore  this  consequent  is  true. 
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7.  Path  A42-44  to  A47,  Case  2 


For  case  2,  the  case  where  the  predicate  of  the  if 
statement  immediately  preceding  A47  is  true,  the  verification 
condition  is: 


A42  a A43  a A44  A i<»jx-l  A 
bop(i)>»first  a eop(i)-0  ^47 

All  of  the  consequents  contained  in  A4  7*  {A45  a A46 } except 
A46  are  restatements  of  the  antecedents. 

a.  (entry-true  a -<  (eop(i)-O))  =£> 

Vz[0<z<-i  ( -i  (bop(z)-first)  a 

(bop(z)  <first  =5>  eop(z) <last) ) ] { A46  ): 

since  eop(i)-0,  the  antecedent  of  this  conditional  is  false, 
and  the  conditional  is  true;  this  completes  the  proof  of  the 
verification  condition  for  this  path. 

8 . Path  A45-46  to  A48  and  Path  A47  to  A48 

There  are  no  program  fragments  on  these  paths,  so  the 
verification  conditions  are  trivially  true;  they  are: 

A45  A A46  A45  a A46 

9 . Path  A48  to  A42-44 

The  verification  condition  is: 

A48=^A39  A A40  A A41  A i+l<-jx 
A A43  A (entry-true  A — ' (eop (i) *0) ) 

Vz[0<z<-i+l  (bop(z) -first) 

a (bop(z)  <first  eop(z)<last) ) ] 

Proof  is  shown  by  considering  the  consequents  one  at  a time. 
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a.  A39  a A40  a A41: 

these  predicates  are  just  a restatement  of  antecedents i 

b.  i+l<-jx: 
i<«jx-l  -=7  i+l<-jx. 

c . A4  3 : 

this  predicate  is  just  a restatement  of  an  antecedent. 

d.  (entry-true  A *■»  (eop(i)-O) ) ^ 

Vz  [0<z<-i+l  ( *”>  (bop  (z) -first) 

a (bop(z)<first  eop(z)<last))]  : 
from  A46  it  is  known  that  the  generalization  on  z is  valid 
over  the  range  0<z<-i,  which  is  equivalent  to  the  range  in  this 
consequent,  namely  0<z<i+l;  therefore  this  consequent  holds. 
Thus,  the  verification  condition  for  this  path  is  proved. 

10.  Path  A42-44  to  A-49-50 

The  verification  condition  is: 

A42  a A43  a A44  a i>jx-l  A49  A A50 
The  consequents  are  considered  one  at  a time. 

a . A4  9 : 

This  predicate  is  a restatement  of  antecedents  of  the  verifi- 
cation condition  and  thus  is  true. 

b.  (entry-true  A -\  (eop( jx)»0) ) 

^z[0<z<»jx  ( -»  (bop(z)-first)  a 

(bop(z)<first  =?>  eop(z)<last))  ] {A50>  : 

i> jx-1  a i<» jx  i-jx. 

Therefore,  this  consequent  is  just  a restatement  of  an  antece- 
dent with  jx-i  replacing  i. 


11 . Path  A39-41  to  A49-50 

The  verification  condition  is: 

{A39-41}  for  statement  {A49-50} 

The  previous  proofs  of  the  verification  conditions  for  paths 
A39-40  to  A42-44,  A42-44  to  A45-46  to  A48,  A42-44  to  A47  to  A48, 
A48  to  A42-44,  and  A42-44  to  A48  satisfy  the  requirements  of 
the  for  rule;  therefore,  the  verification  condition  for  this 
path  is  proved. 

12.  Path.A49-50  to  A51-52,  Case  1 

Case  1 is  the  case  where  entry-false  and  the  compound 
statement  intervening  is  not  executed.  The  verification  con- 
dition in  this  case  is: 

A49  a A50  a entry-false  =£>  A51  a A52 
Consider  the  consequents  one  at  a time. 

a.  A51: 

The  predicates  of  this  consequent  are  restatements  of  given 
predicates . 

b.  A52 : 

entry-false  a A43  =$>A52  (A43  is  one  of  the  predicates  con- 

tained in  assertion  A49) . 

13.  Path  A49-50  to  A51-52,  Case  2 

In  this  case,  entry-true  and  the  compound  statement 
intervening  is  executed.  The  verification  condition  (with 
jx+1  replacing  jx  in  A51-52)  is: 
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A49  a A50  a entry-true  a bop (jx) -first 
a eop(jx)-last 

{ 2<-A<«256  a ca-A  a jx+l>0  a 
Vy[(0<y<jx+1  a bop(y)>l  a 0<eop(y) <A) 

-» (text(bop(y)  -1) -text  (eop(y) +1) ) ] a 
^y[  (0<y<jx+l  A ■"»  (eop(y) -0) ) =» 

[string(bop(y) , eop(y))»ok  a bop(y)>-l  A eop(y)<-A 
aVz(  (0<z<jx+l  a — » ( z— y) ) 

^ ( ~i  (bop(z)-bop(y))  A 
(bop(z) <bop(y)  ■=£>  eop(z) <eop(y) ) ) )]  ]a 

3y(y<jx+l  A l<»bop(y) <-current-l  a current<-eop(y)  <«A  ) 
The  consequents  of  this  verification  condition  are  considered 
one  at  a time. 

a.  2<»A<»256  a ca-A  a jx+l>0: 

these  predicates  are  just  a restatement  of  antecedents. 

b.  Vy[(0<y<jx+1  a bop(y)>l  A 0<eop (y) <A) 

-» (text  (bop  (y)  -l)-text(eop(y)+l))  ] : 

the  antecedent  A40  (contained  within  assertion  A49)  establishes 
the  generalization  on  y for  0<y<jx.  If  the  statement  is  true 
for  y-jx  as  well,  then  this  consequent  is  proved.  The  ante- 
cedents of  the  verification  condition  allow  the  generalization 
statement  for  y*jx  to  be  written  as: 

(first>l  A 0<last<A)  — < » (text (first-1) -text (last+1) ) ; 

from  the  input  assertion  of  this  procedure  it  is  known  that 
(first-1  v'  last-  A v -n(text(first-l)-text(last+l))) ; 
the  generalization  statement  for  y-jx  has  an  antecedent  which 


126 


negates  the  first  two  predicates  of  this  disjunction;  there- 
fore the  third  predicate,  which  is  also  the  consequent  of  the 
generalization  statement  for  y»jx,  must  be  true.  Thus  this 
consequent  of  the  verification  condition  is  proved, 
c.  Vy[  (0<y<jx+l  a -v  (eop(y)*0))=^> 

[string (bop (y) ,eop(y))*ok  a bop(y)>-l 
a eop(y)<s,£  A VZ(  (0<z<jx+l  A -» (z-y)) 

(— • (bop(z)=bop(y)) 

a (bop (z)<bop (y)  ■=$>  eop(z)<eop(y)) ) )]  ] : 

The  antecedent  A41  (contained  within  A49)  establishes  the 
generalization  on  y for  0<y<jx.  If  the  generalization  statement 
is  demonstrated  true  for  y=jx,  then  this  consequent  holds.  For 
the  case  y=jx,  the  conditional  which  must  be  proved  is: 

(last-0)  =€>  [string(first,last)=ok  a first>»l 
a last<=  i \ Vz(  (0<z<jx+l  a -i(z*jx))  -=$>(->  (bop (z)-first) 
a (bop(z)  <first  eop(z)<last))  )] 

The  antecedent  of  the  above  conditional  is  clearly  true;  if 
the  several  consequential  predicates  are  true,  then  the  veri- 
fication condition  consequent  in  question  is  proved.  The  first 
3 predicates  follow  from  the  input  assertion.  The  fourth 
predicate,  the  generalization  on  z,  has  already  been  shown  to 
be  true  for  the  range  0<z<jx 
(from  entry-true  a — > (eop(jx)-O)  a A50) ; 
further,  if  z-jx  then  “t  (z«jx)  is  false  and  the  conditional 
which  is  the  fourth  predicate  is  true. 

This  completes  the  proof  for  this  consequent  of  the  verification 
condition. 
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d.  By(y<jx+1  a l<*bop(y)<*current-l 
a current<=*eop(y)  <■£)  : 

It  is  proposed  that  y*jx  will  satisfy  this  existential  statement. 
jx<jx+l ; 

bop(jx)-first  a l<»first<-£-l  a first<last 
a current<*last  a last<»2. 
l<*bop(jx) < "current -1; 

eop( jx) *last  a current<*last  A last<*t 
current  <=eop  ( jx)  <=*£ ; 

so  y-jx  satisfies  the  existential  statement,  and  this  last 
consequent  of  the  verification  condition  is  shown.  The  veri- 
fication conditions  for  both  cases  on  path  A49-50  to  A51-52 
have  been  proved. 

14.  Input  Assertion  to  Output  Assertion 

The  proof  of  partial  correctness  for  this  procedure 
is  completed  by  concatenation  of  paths  A39-41  to  A49-50  and 
A49-50  to  A51-52. 

15 . Termination 

The  procedure  has  one  entry  and  one  exit,  the  only 
loop  is  a for  statement;  therefore,  the  procedure  terminates. 


K.  PROCEDURE  MAIN 

Figure  8 contains  the  assertions  for  the  main  body  of  the 
example  program. 

' * 

1.  Input  Assertion:  AO. 


CO 


■■•■t  Hlai 
Ms  C 20  Inpet  ( 1)0286  A ca»«  3 
laltiallMi 

A3:  ( 2<  ■ 1<  *286  A ca*6  A jx«  1 A lt*88A  cb'klani  ) 

raa4_and.Kr lte_ Inpat— cardat 

A16 : ( 20  10286  A caB  1 A jx«  1 3 

pa  1 iadroaw— check: 

A83:  ( 2010286  a cm*  1 a Jx>«  3 

AS4:  ( V*[(2<**<«l  a t«it(rl)»t«*t(x))^ 

3y<y<jx  a 10bop(y)0x-l  A x0eop<y)01)3  ) 

A88«  t Vx£(30x0I  a l»xt(*-2)*taxt(i))^ 

3y<y<jx  a !Obop<y)Ox-2  a x<  *eop(  y)<  * 1 ) 3 3 
A36:  t VyC  (•<  y<  jx  A bop(  y)  > 1 a 0<  #op(  y)  < 1 ) =*> 

text < bop<  y)  — 1 ) ■ text  ( eopl  y)  + 1 ) ) 3 ) 

AS7:  ( Vyt  <6<y<jx  A «*<  eop(  y)  »0)  )-4> 

t ■ tr  la»(  bop(  y)  , eop(  y) ) *ok  a bop(y)>*l  a eop(y)Ot 
a v'xl  (<Kx<jx  a **<z»y)>^> 

( ~<  bop(x)  *bop(  y)  ) a (bop(x)<bop(y)  ^ aop(z)<«op(y)))  )]  3 3 

if  jx* 1 the a text3 

elae  «r 1 te— a 1 1— pa  I Indroaee t 

A88:  ( AS3  A AS4  A ASS  A AS6  A AS7  3 

end. 


FIGURE  8 

PROCEDURE  MAIN 


129 


■SSIS^V  " 


4HSP* 


2.  Output  Assertion: 


A5  8. 


3.  Intermediate  Assertions: 

The  intermediate  assertions  are  assertions  A3,  A16,  and 
A53-57.  They  are  precisely  the  input  and/or  output  assertions 
of  the  procedure  calls  they  precede  and/or  follow.  The  veri- 
fication condition  path  for  assertion  AO  to  A53-57  is  proved 
by  repeated  application  of  the  rule  of  inference  for  procedure 
calls,  and  then  by  concatenation.  The  verification  condition 
for  path  A53-S7  to  AS8  is  simply: 

{A53-57}  non-significant  statement  [A53-57}  , 
because  the  intervening  i^f  statement  merely  prints  the  results 
which  have  already  been  proven  correct;  its  proof  is  immediate. 

4.  Termination 

All  of  the  procedures  called  from  this  main  body  have 
been  shown  to  terminate;  this  program  has  one  entry,  one  exit 
and  no  loops;  therefore,  it  terminates.  This  completes  the 
proof  of  total  correctness  of  the  example  program. 
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APPENDIX  B 


APPLICATION  OF  DISTRIBUTED 
CORRECTNESS  TECHNIQUES 

A.  ASSUMPTIONS,  ABBREVIATIONS,  AND  NOTATION 

In  addition  to  the  assumptions  about  the  example  program 
verified  by  static  analysis  (Chapter  IV,  Section  A) , it  was 
further  assumed  that  all  input  data  read  by  the  program  were 
type  compatible  with  variables  and  that  the  correct  number  of 
input  characters  were  present  in  the  input  data  stream.  Integer 
arithmetic  was  also  assumed.  Because  actual  dynamic  testing 
was  involved,  assumptions  that  the  operating  system  and  compiler 
operated  correctly  were  at  least  partially  verified  during 
testing. 

Because  several  of  the  program  variable  names  are  verbose, 

the  abbreviations  listed  below  were  used  in  presenting  the 

assertions  and  their  verification: 

-l  length-‘-of«-text 

-At  cardlimit 

-cb  cardbuffer 

-n  number«-of«-input-‘-cards 

-c  card«-counter 

-bp  bufferposition 

-bop  begin«-of«-palindrome 

-eop  end-*-of«-palindrome 

-p  palindrome 

Figures  9 through  12  are  listings  of  four  program  procedures 
with  labeled  synthetic  assertions  inserted  to  aid  the  discussion 
of  the  correctness  demonstration.  Assertions  BO  and  B29-33  are 
the  input  and  output  specifications,  respectively.  Assertions 
are  contained  within  braces  " ( ),M  and  in  Figures  9 through  12 
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wherever  successive  labeled  assertions  follow  a program  state- 
ment, the  intended  synthetic  assertion  for  that  point  is  a con- 
junction of  those  assertions.  Frequently  assertions  contain 
within  the  braces  the  names  (labels)  of  other  assertions;  the 
meaning  implied  is  a literal  replacement  of  the  label  with  its 
expansion. 

Condition  tables  in  the  following  sections  list  on  their 
left  the  several  predicates  which  were  considered  to  partition 
the  input  domain  of  the  given  program  fragments.  The  columns 
to  the  right  of  the  predicates  list  the  conceivable  combinations 
of  truth  values  for  the  several  predicates.  Corresponding  to 
each  column,  a test  data  element  was  selected  to  verify  program 


operation  for  each  composite  predicate  (conjunction  of  the  truth 

value  entries  in  each  column) . The  following  entries  were  used 

in  the  columns: 

y : Yes,  or  true, 

n : No,  or  false. 

: Don't  care;  either  true  or  false. 

(y)  : Required  to  be  true  by  the  value  for 

another  entry  in  the  same  column. 

(n)  : Similar  to  (y) , except  false. 


B.  UTILITY  PROCEDURES 


The  procedures  "textl,"  "text2,"  "text3,"  "blank*- lines 
and  "write*-all*-palindromes"  do  not  affect  program  performance 
of  the  output  specification.  (They  effect  the  neat  printing 
of  the  results  obtained  in  the  significant  procedures.)  As  in 
the  presentation  of  the  formal  proof  for  the  example  program, 
these  procedures  will  not  be  examined  here.  However,  it  should 
be  noted  that  because  the  method  reported  in  this  appendix 
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involved  actual  program  execution,  a side  effect  of  the  tests 
performed  was  to  verify  the  performance  of  these  non-essential 
procedures . 


C.  PROCEDURE  MAIN 

The  methodology  using  the  principle  of  distributed  correct- 
ness and  the  condition  table  method  for  selecting  test  data 
(where  needed)  was  first  applied  to  the  main  body  of  the  example 
program;  procedure  calls  were  treated  either  as  an  in-line  ex- 
pansion of  code  or  as  program  statements  whose  semantic  meaning 
was  defined  by  the  input  and  output  assertions  of  the  called  pro- 
cedure. It  was  assumed  that  the  input  assertion  BO  is  satisfied 
when  program  execution  begins.  Figure  9 contains  the  synthesized 
assertions  for  this  procedure. 

1 . Synthesized  Assertion  Bl: 

2<=£<=256  a jx=l  a £t=80  A cb=blank 


a.  Test  Data  Assertion  and  Verification 

The  test  data  assertion  is  that  for  £=2  and  for  any 
corresponding  character  string  (of  length  2) , the  synthesized 
assertion  is  valid.  Verification  was  obtained  by  executing  the 
program  statement  "initialize;"  preceeding  assertion  Bl  with 
input  data  £*2. 

b.  Generalization  Assertion  and  Verification 

The  generalization  assertion  is  that  for  any  input 
data  satisfying  the  input  assertion  BO,  the  same  result  as  above 
will  be  obtained.  Verification  is  made  by  static  analysis  of 
procedure  "initialize"  - the  assignments  satisfying  Bl  are 
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CO 

M:  C 2<*1<"256  ) 

lal t la  1 lit i 

Bis  C 20  10236  A jx«  1 A lt*8B  A cb=blank  3 

read-and— wr 1 te_inpnt_carda t 

BB:  t 20  10256  a«*»1  a jx*  1 3 

pa l indroae —check* 

If  jz>l  than  t«at3 

elae  write— all— pal Indroaeas 

B29 s ( 20  10296  A ca*  1 A jx>6  3 
B3B:  (VxC(20x01a  t«xt(  x-  1)  * text(  x)  ) =9 

3y(y<jx  A 1<  =*bop(  y)  < =>x-  1 A x0eop(y>01)3  3 

B31 : C VxCCSOxOl  a text  ( x-2)  * text  ( x) 

3y<  y<  jx  a 1<  -bop(  y)<  *x- 2 a x<  seop<  y)<  ■ 1)  3 3 
B32:  C VyC  (®<  y<  jx  a bop(y)>  1 A «<eop(y)<  1)-^ 

~<  text(bop<y)-l)3text(eop(y)  + l)  3 3 3 
B33:  C VyC  (9<y<jx  A ~<  aop(  y)  3«>  )-=» 

C a tr  lng< bop<  y)  , eop<  y)  ) *«k  a bop(y)>'l  a eop(y)0  1 
/\Vz<  (0<z<jx  a ~<z3y))^* 

( ~< bop< z) *bop< y) ) a ( bop( z) < bop< y)  ^ eopC z) < eop< y) ) ) >333 

end. 
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executed  unconditionally. 

c.  Proof  of  Synthesized  Assertion 

The  synthesized  assertion  follows  directly  from 
the  test  data  and  generalization  assertions.  Note  that  the 
procedure  call  "initialize;"  was  treated  as  an  in-line  sub- 
stitution of  code.  The  proof  of  B1  amounted  to  a demonstration 
of  correctness  of  the  procedure  "initialize." 

2 . Synthesized  Assertion  B5: 

2<=£<*256  A ca=  A a jx=l 

The  control  path  from  assertion  B1  to  B5  contains  only 
a procedure  call  to  "read-*-and-<-write«-input-*-cards" ; assertion  B5 
is  proved  by  showing  that  it  is  equivalent  to  the  output  speci- 
fication of  the  procedure. 

Let  assertion  B2  be  identical  to'Bl,  and  let  it  be  the 
input  assertion  for  procedure  "read-«-and-<-write-<-input't-cards"  (see 
Figure  4 in  Appendix  A) ; clearly  B2  holds  since  B1  precede  the 
procedure  call  and  has  been  shown  true.  Examination  of  the 
procedure  reveals  that  the  predicates  2<=£<*256  and  jx*l  are 
not  modified  in  its  execution;  only  the  predicate  ca-l  (which 
as  before  means  that  "A"  characters  have  been  properly  read 
from  the  input  stream  and  assigned  to  the  string  variable  "text" 
in  the  proper  position)  remains  to  be  shown.  This  will  be 
done  by  verification  of  the  output  assertion  for  the  procedure 
called. 

a.  Synthesized  Assertion  B3: 

Let  B3  be  an  assertion  inserted  following  the 
first  statement  in  "read-*-and-*-write-*-input«-cards" 
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(n:-((A-l)div  At)+1;).  The  assertion  is  that: 

"n"  is  the  correct  number  of 
input  cards  for  the  characters 
in  a string  of  length  "A." 

The  test  data  assertion  for  B3  was  determined  using  the 
following  condition  table  to  divide  the  input  domain  into 
equivalence  classes: 

Predicate 


2<=»A<=  80 

y 

(n) 

(n) 

(n) 

81<“A<=160 

(n) 

y 

(n) 

(n) 

161<=A<*240 

(n) 

(n) 

y 

(n) 

24K»A<»256 

(n) 

(n) 

(n) 

y 

Test  data  (A) 

2 

81 

240 

256 

Correct  value  (n) 

1 

2 

3 

4 

The  test  data  assertion  (i. 

e . , that 

the 

program 

will 

execute 

properly  for  the  test  data 

elements 

identified 

in  the 

preceding 

table)  was  verified  by  execution  of 

the 

program 

to  assertion 

B3  with  the  four  test  data  values  of  "A"  and  checking  for  the 
assignment  of  the  correct  value  to  "n". 

The  generalization  assertion  at  B3  is  that  n is  totally 
determined  by  the  four  predicates  on  "A"  given  in  the  condition 
table;  from  the  program  statement  "n:*((A-l)div  At)+1M  and  the 
predicate  At*80  it  is  apparent  that  this  is  so. 

The  proof  of  the  synthesized  assertion  B3  follows  directly 
from  the  test  data  and  generalization  assertions  and  Theorem  2.1 
of  Reference  14  (the  theorem  states  that  if  two  functions  on 
the  same  domain  D are  totally  determined  by  the  same  predicates. 
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then  those  predicates  partition  D into  equivalence  classes  for 
testing  purposes).  Theorem  2.1  applies  in  this  case  as  the 
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program  performance  (first  function)  and  the  assignment  algorithm 
(second  function)  are  both  totally  determined  by  the  four  pre- 
dicates on 

b.  Synthesized  Assertion  B4: 

Let  B4  be  inserted  following  the  last  statement  in 
procedure  Mread^and^write^-input^cardsM  (i.e.,  the  output 
assertion  for  the  procedure).  The  assertion  is: 

ix^A+l  a ca*£ 


The  test  data  assertion  for  B4  was  determined  using 
the  following  condition  table  to  divide  the  input  domain  into 
equivalence  classes: 


Predicate 


2<*£<  80 

y 

n 

n 

n 

2<*£<*256  a l rem80=0 

(n) 

y 

y 

n 

80<4<*256 

(n) 

n 

y 

Cy) 

n»l 

(y) 

Cy) 

(n) 

Cn) 

n>l 

(n) 

(n) 

Cy) 

Cy) 

Test  data  ( s)  * 

2 

80 

160 

81 

Correct  value  (ix) 

3 

81 

161 

82 

*An  input  string  of  "t” 

characters 

must 

also  be  provided. 

The  predicates  listed  above  are  those  which  were  presumed  to 
have  all  possible  bearing  on  program  operation;  note  that  the 
two  predicates  on  "n"  were  actually  unnecessary  since  "n"  is 
totally  determined  by  "i." 
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The  test  data  assertion  is  that  the  correct  results  will  be 


obtained  for  the  four  test  data  elements  identified  in  the  con 


dition  table;  verification  was  successfully  performed  by  program 


The  generalization  assertion  at  B4  is  that  ix  is  totally 
determined  by  the  three  predicates  on  "i"  listed  in  the  condition 
table  (and  "ca"  is  one  less  than  ix) . This  was  verified  by  in- 
spection of  the  program  statements  between  assertions  B3  and  B4. 

The  proof  of  the  synthesized  assertion  B4  follows  directly 
from  test  data  and  generalization  assertions  and  Theorem  2.1  (14) 
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c.  Proof  of  Synthesized  Assertion  B5 

It  has  been  shown  that  assertion  B1  preceding  the 
call  to  procedure  "read+and-^write+input+cards"  satisfies  the 
input  assertion  for  the  procedure,  and  that  the  procedure 
correctly  assures  the  validity  of  its  output  assertion  (B4) . 

Since  B4  requires  that  caat,  synthesized  assertion  B5  is  shown 
by  the  distributed  correctness  of  the  called  procedure. 

3.  Synthesized  Assertion  B29-33 

The  assertions  B29-33  are  the  output  specification  for 
the  example  program.  The  only  significant  program  statement 
intervening  between  assertion  B5  and  B29-33  in  the  main  program 
is  a call  to  procedure  "palindrome+check"  (Figure  10  is  a listing 
of  the  procedure) . Note  that  assertion  B5  satisfies  the  input 
assertion  (B6-8)  to  the  procedure  (because  B6  is  a restatement 
of  B5  and  the  conditionals  which  constitute  assertions  B7  and  B8 
have  antecedents  which  are  necessarily  false  when  jx»i;  therefore 
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the  conditionals  are  true)  and  that  the  output  assertion  of  the 
procedure  (B12)  is  identical  to  assertion  B29-33.  Therefore, 
if  the  distributed  correctness  of  procedure  "palindrome*- check" 
is  shown  separately  and  if  the  procedure  call  statement  is  exe- 
cuted for  the  test  cases  identified  in  the  verification  of  the 
procedure,  then  the  synthesized  assertion  B29-33  is  demonstrated 
to  be  true,  and  the  verification  of  the  main  program  is  complete. 
The  correctness  of  the  called  procedure  is  demonstrated  in  the 
next  section. 

D.  PROCEDURE  PALINDROME  CHECK 

Figure  10  contains  the  synthesized  assertions  for  this  pro- 
cedure. Similar  to  the  way  correctness  of  the  main  program  was 
verified  by  relying  on  the  distributed  correctness  of  this  pro- 
cedure, this  procedure  will  be  verified  by  relying  on  the  dis- 
tributed correctness  of  the  procedure  which  it  calls,  namely 
"continue  checking." 

1.  Synthesized  Assertion  B6-8: 


B6 : 2<*£<*256  A jx*l  a ca=£ 

B7:  V y[(0<y<jx  a bop(y)>l  A 0<eop(y)<t)  =^> 

-* (text (bop (y)  -l)=text(eop(y)+l))  ] 

B8:  Vy[  (0<y<jx  a ~»(eop(y)*0) ) ==>> 

[stringCbop(y) ,eop(y) )»ok  a bop(y)>*l  a eop(y)<*£ 
a VZ(  (0<z< j x A -»(z«y))=^> 

("•  (bop  (z)  *bop  (y) ) 

a (bop(z)<bop(y)  eop(z)<eop(y)))  )]  } 

Synthesized  assertion  B6-8  is  the  input  assertion  for  the 
procedure.  Static  analysis  of  the  program  reveals  that  the 
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coMiot  find  all  pal  lndroaas  within  flw#  taxt  strings 
bavin 
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t 2<  * 1<  *286  A J*“  1 A ca*  1 ) 

C VyC!«<y<jxA  bop< y) > 1 A »<«op(y)<l)^ 
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( 'dyt  !B<y<Jx  A "(aop(  y)»*))^ 

Catr  laglboply)  .aoply)  )»ok  a bop!y)>*t  A aip(y><*l 
a Vj(  (»<z<ji  a *-<z*y)>*^ 

( **<  boplx)  *bop!  y)  ) a !bop!  xKboply)  aoplzXaop!  y>  > > >3  1 


for  lx!*2  atop  1 until  langth_o f-taxt  do 
bag  in 

if  tazt < lx*- 1 ) * tert<  lx)  than 


t 2<  * 1<  *286  A jx>0  A ca*  1 A B7  A BB  ) 
t taxt! lx-l)*taxt( lx)  a atart*ix-l  A finish* lx 
a string!  lx-1,  lx)*ok  A K*lx-1A  ix<*l  ) 


eont inua_c backing!  ( lx— 1 ) , lx) j 
if  ix  ~*  2 than 

if  taxt! ix-2)* text! lx)  than 


B1 1 : 


t B*  A text! lx-2) ■ taxt! lx) A atart*lx-2A  finish*  lx 

A string! lx-2, lx)*ok  A l<»lx-2  a lx< * 1 ) 


and  i 


cont  inns— chocking! ! lx-2) , lx) i 


{ 2<*1<*256  A ca* 1 a jx>«  a B30  A B31  a B82  A B33  ) 
and  pal  indro— -chocks 


FIGURE  10 

PROCEDURE  PAL  INDROME-*- CHECK 


140 


=1 


only  call  to  procedure  "palindrome^check"  is  the  call  in  "main" 
following  assertion  B5;  assertion  B5  is  identical  to  B6,  there- 
fore B6  holds  at  the  time  of  the  procedure  call.  B5  ensures 
that  jx-1,  and  because  there  is  no  integer  y such  that  0<y<l, 
the  antecedents  of  the  conditionals  which  constitute  B7  and  B8 
are  necessarily  false  at  the  time  of  the  procedure  call.  There- 
fore the  conditionals  must  be  true  at  this  point,  and  the  input 
assertion  to  the  procedure  is  satisfied  whenever  it  is  called. 

2 . Synthesized  Assertion  B9-10: 

B9 : 2<*£<*256  a.  jx>0  a ca*£  a B7  a B8 

BIO:  text(ix-l)*text(ix)  a start*ix-l  a finish-ix 

a string(ix-l,ix)=ok  a l<»ix-l  a ix<*£ 

The  assertion  B9-10  is  inserted  to  state  that  the  input 
specification  is  satisfied  for  the  procedure  "continued-checking,' 
which  is  called  immediately  following  the  assertion.  All  pre- 
predicates of  B9-10  are  a restatement  of  the  input  assertion 
B6-10  (and  have  not  been  modified  by  the  intervening  program 
statements)  except: 

a.  text(ix-l)=text(ix) : 

this  predicate  is  assured  since  control  reaches 
B9-10  only  if  it  is  satisfied  (preceding  .if  statement). 

b.  start*ix-l  A finish*ix: 

these  predicates  are  true  by  definition;  "start" 
and  "finish"  are  constants,  initialized  to  the  values  with  which 
"continued-checking"  will  be  called,  which  are  used  in  the 
proofs  of  synthesized  assertions. 


c. 


string(ix-l , ix) »ok: 

follows  immediately  from  text (ix-l)*text(ix) . 


■ 

| 

I 

; j 


!; 


i 


d.  jx>0  A B7  a B8: 

these  predicates  hold  on  the  first  loop  iteration 
because  of  the  input  assertion;  they  hold  on  subsequent  itera- 
tions due  to  the  distributed  correctness  of  "continue  checking" 
(they  are  contained  within  the  procedure's  output  assertion). 

The  preceding  discussion  reveals  that  the  synthesized 
assertion  B9-10  is  always  valid;  thus  no  test  data  and  generali- 
zation assertions  are  required. 

3.  Synthesized  Assertion  Bll: 

Bll:  B9  a text(ix-2)=text(ix)  a start-ix-2  A finish=ix 

a string(ix-2,ix)»ok  a l<*ix-2  a ix<=£ 

The  assertion  Bll  is  inserted  to  state  that  the  input 
specification  is  satisfied  for  the  procedure  "continued-checking," 
which  is  called  immediately  following  the  assertion.  In  a 
fashion  similar  to  that  discussed  above,  it  may  be  verified  that 
assertion  Bll  always  holds,  and  no  test  data  and  generalization 
assertions  are  required. 

4.  Synthesized  Assertion  B12: 

2<*i<*256  A ca*Jl  A jx>0  a B30  A B31  A B32  a B33 
Assertion  B12  is  the  output  assertion  for  procedure 
"palindromed-check";  the  expansions  for  assertions  B30  through 
B33,  which  are  predicates  of  assertion  B12,  are  given  below: 


l 
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B30:  Vx [ (2<*x<»Jl  A text(x-l)*text(x) ) 

3y(y<jx  a l<*bop(y)<*x-l  a x<*eop(y) <*t) ] 

B31:  Vx[(3<*x<=A  a text  (x-2) “text (x) ) => 

5y(y<jx  a l<*bop(y) <*x-2  A x<aeop (y) <“4) ] 

B32:  V y [(0<y<xj  A bop(y)>l  a 0<eop(y)<£) 

“'(text (bop (y) -l)“text(eop(y)+l)) ] 

B33:  ^y[  (0<y<jx  a “*  (eop(y)  “0) ) =*> 

[string (bop(y)  ,eop(y))«ok  ^ bop(y)>*l  a eop(y)<“  i 
a Vz(  (0<z<jx  a ~»(z“y))=^ 

( “i  (bop  (z)  «bop  (y) ) A (bop  (z)<bop  (y)  =*>eop  (z)  <eop  (y) ) ) )]  ] 

The  truth  of  assertion  B12  may  be  verified  partially  through 
logical  techniques  and  partially  through  dynamic  testing.  By 
static  analysis  it  is  noted  that  if  during  execution  of  the 
procedure  no  statements  which  call  "continued-checking"  are 
actually  executed,  then  all  the  predicates  of  assertion  B12  are 
merely  restatements  of  the  input  assertion  B6-8  and  are  not 
modified  by  program  execution  (no  positive  processing  takes 
place) . 

If  calls  to  "continued-checking"  are  executed,  then  from  the 
output  assertion  of  that  procedure  and  the  principle  of  distri- 
buted correctness  (the  demonstration  of  correctness  and  a listing. 
Figure  11,  of  that  procedure  are  presented  subsequently),  the 
following  predicates  remain  unchanged  by  execution  of  the  pro- 
cedure : 

2<«8,<“256  a ca-fc  a jx>0  a B32  A B33 

The  predicates  B30  and  B31  will  be  demonstrated  through 
testing  in  the  following  manner.  If  "continued-checking"  is 
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called  with  actual  parameters  "start"  and  "finish",  then  its 
output  assertion  verifies  that: 

3y(0<y<jx  a l<»bop(y)<*start  a finish<*eop (y) <*&) 
Predicates  B30  and  B31  are  verified,  and  thus  so  is  the  syn- 
thesized assertion  B12,  if  it  is  shown  that: 

Vx(2<»x<*4  a text (x-1) »text(x)  =>> 

"continued-checking"  is  called, 
with  start-x-1  and  finish=x;  and 
Vx(3<*x<*«.  a text  (x-2)  “text  (x) -=3> 
"continued-checking"  is  called, 
with  start»x-2  and  finish“x. 

a.  Test  Data  Assertion  and  Verification 

It  was  presumed  from  static  analysis  of  this  proced- 
dure  that  if  procedure  calls  are  correctly  mode  to  "continued- 
checking"  for  the  first  three  characters  of  a text  string, 
they  will  be  correctly  made  for  all  characters.  (Only  the 
character  patterns  over  a sub -string  of  length  three  are  examined 
by  the  statements  which  determine  whether  and  when  to  call 
"continued-checking".)  Thus  test  data  were  selected  to  consider 
all  possible  conditions  arising  in  the  first  three  characters. 

A condition  table  was  prepared  as  follows: 


/ 
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Predicate 


2.-2  A ix-1 

y 

n 

n 

n 

n 

n 

. n 

n 

n 

n 

n 

2.-2  a ix-2 

00 

y 

y 

n 

n 

n 

n 

n 

n 

n 

n 

2.-3  A ix-1 

(n) 

(n) 

(n) 

y 

n 

n 

n 

n 

n 

n 

n 

2>3  A ix-2 

(n) 

(n) 

(n) 

Cn) 

y 

y 

n 

n 

n 

n 

n 

2,-3  a ix-3 

Cn) 

00 

(n) 

Cn) 

Cn) 

Cn) 

y 

y 

y 

y 

y 

:ext(l)»text(2) 

- - 

y 

n 

- 

y 

n 

y 

y 

n 

n 

n 

text (l)-text (3) 

- 

- 

- 

- 

- 

- 

y 

n 

y 

n 

n 

text (2) -text (3) 

• 

— 

- 

• 

“ 

— . 

(y) 

(n) 

Cn) 

n 

y 

Test  Data:  (2.) 

* 

2 

2 

* 

3 

3 

3 

3 

3 

3 

3 

(text) 

bb 

ab 

bbb 

aba 

bbb 

bba 

aba 

abc 

abb 

*These  compound  predicates  cannot  be  satisfied 
for  any  input  data  values. 

The  preceding  condition  table  identifies  seven  unique  test 
data  elements  which  were  input  to  the  program  for  dynamic  testing. 
Correct  results  were  obtained  for  all  elements;  the  correct  re- 
sults were  defined  as  being  the  recording  in  the  arrays  "bop" 
and  "eop"  of  entries  which  included  those  character  positions 
corresponding  to  all  truth  values  of  "y"  in  the  three  rows  of 
predicates  on  "text". 

bi  Generalization  Assertion  and  Verification 

The  generalization  assertion  is  that  the  preceding 
predicates  totally  determine  the  procedure  calls  made  to 
"continued-checking",  and  thus  the  results  recorded  in  the  arrays 
"bop"  and  "eop".  Verification  of  this  assertion  was  not 
formally  stated;  verification  relies  on  the  thoroughness  with 
which  the  applicable  condition  table  was  prepared. 

\ 

c.  Proof  of  Synthesized  Assertion 

The  synthesized  assertion  follows  from  the 
discussion  preceding  the  presentation  of  the  applicable 
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condition  table  and  from  the  test  data  and  generalization 
assertions.  Sufficiently  general  theorems  to  formally  state 
a proof  of  the  assertion  weTe  not  available  or  forthcoming 
from  this  effort;  however,  the  careful  analysis  of  predicates 
built  a high  confidence  that  the  program  fragment  is  correct. 

H.  PROCEDURE  CONTINUE-*- CHECKING 

Figure  11  contains  the  synthesized  assertions  for  this  pro- 
cedure. The  input  assertion  is  B13-16;  since  it  was  verified 
in  the  preceeding  section  that  this  assertion  was  satisfied  for 
all  calls  to  this  procedure,  it  will  be  assumed  that  this 
assertion  is  satisfied  at  the  time  of  invocation  of  this  pro- 
cedure. 

1.  Synthesized  Assertion  B17-18; 

B17 : B13  A B14  A B15 

B18:  text(first)“text(last)  a l<*f irst<*start 

a finish<*last<*Jl  a string(first , last)*ok 
a (finish*start+l  V finishes tart+2)  A 
(first=l  v last**  V -\  (text(first-l)*text (last+1) ) ) 

a.  Test  Data  Assertion  and  Verification 

Test  data  were  selected  using  the  condition  table 
method  to  consider  all  predicates  which  were  considered  to 
have  a bearing  on  program  processing  with  respect  to  assertion 
B17-18.  The  applicable  condition  table  is  presented  below,  in 
two  sections. 


B13: 

B14: 


BIS: 


BIS: 


BI7 : 
B18: 


B19: 

B20: 


procedure  coal  inue— checkin*  (Integer  nine  first,  lent): 
consent  Olsen  first  end  lsst  ns  pointers  to  a pelindroae 

of  size  2 or  3.  this  procedure  checks  whether  or  not  this 
pallndrone  is  Included  in  a larger  palindrome: 

begin 


C 2<  3 1<  *256  A ca*  1 A jx>*  ) 

{ Vyt  ( 0<  y<  jx  a bop(  y)  > I a 0<eop(  y)<  1 ) ^ 

"(  text<  bop<  y)  - 1)  3 text  ( eop(  y)  + 1)  ) ] ) 

C Vyt  <0<y<jx  a -*<  eop(  y)  *0) 

t etr  lng(bop(y)  , eop(y)  )>ok  a bop(y)>3l  A eop(y)<  = l 
a V x(  (0<z<jx  A >»(z>y))'^ 

( **<  bop(  z)  »bop(  y)  ) a (bop(z)<bop(y)  ^ eop(z)<  eop:  y)  > > 
{ text!  first)3 text( last)  a start  = flrst  a finish3 last 
a ■ tr ing( f irs  t , las  t ) 3 ok  a 1<  «« tart  a flnish<  = l 
a ( f lnish3s  tart+ 1 V f lnishas tar t+2)  1 


>1  1 } 


logical  pallndroew; 
pa  i indrotae  : 3 true : 

while  ((flrat>l)  and  ( las t< length_of— text ) and  ( pa  1 indrone3 true ) ) do 
begin 

if  text( f Irs t-1)  3 text  (las  t+1)  then 
begin 

coasaent  larger  pallndrone  found: 
f lrst:3f lrst-1: 
las t : 3 las t+1 : 
end 

e lse 

begin 

pal Indroastefalse:  counent  largest  pallndroaw  found; 

end: 

end : 


C B13  A B14  a BlS  } 

C text( f lrst)3text< last)  A 1< 3 f irs t< 3s tar t A f ins ih< 3 las t< 3 1 
a a tr ing( first , last) 3ok  A ( f lnish3s tar t+ 1 v f lnlsh3s tar t+2) 
A ( f irs  t* 1 v last3  1 V ~( text ( f irs t- 1) 3 text ( las  t + 1 ) ) ) 1 


record-pa  1 lndrons( f irs  t , last) : 


( B13  A B14  a BIS  ) 

( 3y(0<y<jx  A 1< 3bop( y>< 3start  a f lnlsh< «eop( y) < 3 1 ) ) 


end  cont Inue -checking; 


Predicate 


start+l®finish 

n 

y 

y 

X 

- - 

y 

y 

y 

start+2*finish 

n 

(n) 

(n) 

(n) 

- 

(n) 

(n) 

(n) 

start»l 

- 

y 

y 

y 

- 

n 

n 

n 

start*2 

- 

(n) 

(n) 

(n) 

- 

y 

y 

y 

start>2 

- 

(n) 

(n) 

(n) 

- 

(n) 

(n) 

(n) 

finish*^ 

- 

y 

n 

n 

n 

y 

n 

n 

finish*4-l 

- 

(n) 

y 

n 

n 

(n) 

y 

y 

finish<£-l 

- 

(n) 

(n) 

y 

n 

(n) 

(n) 

(n) 

text (start-1) = 

text(finish+l) 

- 

- 

- 

- 

- 

- 

y 

n 

text(start-2)» 

text (finish+2) 

• 

* 

• 

*• 

• 

*• 

Test  Data:  (&) 

* 

2 

3 

4 

* 

3 

4 

4 

(text) 

aa 

aab 

aabc 

abb 

abba 

abbc 

*These  compound  predicates  cannot  be  satisfied 
for  any  input  data  values. 


Predicate 

start+l»finish 

y 

y 

y 

y 

y 

y 

y 

y 

start+2»finish 

(n) 

(n) 

(n) 

(n) 

(n) 

(n) 

(n) 

(n) 

start»l 

n 

n 

n 

n 

n 

n 

n 

n 

start*2 

y 

y 

n 

n 

n 

n 

n 

n 

start>2 

Cn) 

(n) 

y 

y 

y 

y 

y 

y 

finish®*- 

n 

n 

y 

n 

n 

n 

n 

n 

finish® £-1 

n 

n 

Cn) 

y 

y 

n 

n 

n 

finish<t-l 

y 

y 

(n) 

(n) 

(n) 

y 

y 

y 

text(start-l) ■ 

text (finish+1) 

y 

n 

- 

y 

n 

y 

y 

n 

text(start-2)= 

text(finish+2) 

*■ 

y 

n 

Test  Data:  (2.) 

5 

5 

4 

5 

5 

6 

6 

6 

(text) 

A 

B 

C 

D 

E 

F 

G 

H 

A:  abbad 

B: 

abbcd 

C: 

abcc 

D: 

abccb 

E:  abccd 

F: 

abccba 

G: 

abccbd 

H: 

abccde 

The  preceding  condition  table  identifies  fourteen  test 
data  elements;  these  were  used  as  input  to  the  program  for 


dynamic  testing.  Correct  results  were  verified  for  all  ele- 
ments by  printing  variable  values  following  assertion  B17-18 
and  verifying  that  the  predicates  of  the  assertion  were  satis- 
fied. During  presentation  of  the  preceding  condition  table, 
no  columns  with  an  "n"  entry  for  the  first  predicate  and  a "y" 
entry  for  the  second  were  added  because  no  new  insights  to  the 
procedure's  operation  would  have  been  gained. 

b.  Generalization  Assertion  and  Verification 

The  generalization  assertion  is  that  the  satisfaction 
of  the  synthetic  assertion  B17-18  is  totally  determined  by  the 
predicates  of  the  condition  table;  the  only  verification  was 
the  analysis  which  served  as  a basis  for  the  preparation  of  the 
table. 

c.  Proof  of  Synthesized  Assertion 

The  synthesized  assertion  follows  from  the  test 
data  and  generalization  assertions.  No  formal  proof  could  be 
offered. 


2 . Synthesized  Assertion  B19-20: 

B19 : B13  /v  B14  a B15 

B20:  3y(0<y<jx  A l<=bop(y) <*start  a finish<=ecp (y) <*£) 

Assertion  B19-20  is  the  output  assertion  for  this  procedure. 
Inspection  of  Figure  12,  the  listing  and  assertions  for  proce- 
dure "record**-pal  indrome"  reveals  that  assertion  B17-18,  which 
precedes  the  only  call  to  that  procedure,  which  call  in  turn 
precedes  assertion  B19-20,  satisfies  the  input  assertion  to 
"record«-palindrome" , and  further  that  the  output  assertion  of 
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"record«-palindrome"  satisfies  assertion  B19-20,  Therefore  syn- 
thesized assertion  B19-20  is  verified  by  the  correctness  of 
"record*-pal  indrome"  (which  is  shown  in  the  next  section) , and 
test  data  and  generalization  assertions  are  not  required  here. 


► 


F.  PROCEDURE  RECORD*- PALINDROME 

Figure  12  contains  the  synthesized  assertions  for  this  pro- 
cedure. The  input  assertion  is  B21-24;  since  it  was  verified 
in  the  preceding  section  that  this  assertion  is  satisfied  when- 
ever the  procedure  is  called,  the  input  assertion  is  assumed 
to  hold  at  procedure  invocation. 

1.  Synthesized  Assertion  B25: 

B21  a B22  a B23  A B24  A entry=true 
a.  Proof  of  Synthesized  Assertion 

The  test  data  and  generalization  assertions  are 
simply  the  observation  that  any  and  all  input  data  will  cause 
the  execution  of  the  statement  assigning  "entry"  equal  to  true; 
the  rest  of  the  assertion  is  a restatement  of  the  input  asser- 
tion, none  of  which  has  been  modified.  Verification  was  post- 
poned until  the  verification  of  the  test  data  assertion  for 
synthesized  assertion  B26.  The  proof  of  synthesized  assertion 
B25  follows  directly  from  this  observation. 

2.  Synthesized  Assertion  B26: 

(entry»false  a B27  a B28)  V 
[entry=true  A B21  A B22  a B23  A B24 
A Vz (0<z< jx  =#(  — '(bop(z)-first 
a (bop(z) <first  *$>eop(z) <last) ) ] 
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procedure  record— pa 1 Indr  one  (Integer  value  first,  last): 
coneent  Record  only  nun  length  pallndronoo.  Flog  previously 

recorded  palindrosms  If  they  ore  Included  In  the  pollodr 
specified  by  first  and  loot. 

jx  woo  Initialized  to  1.  After  completion  jx  points  to 
next  entry  lu  begin— o f_po 1 Indrome  and  ead-of-pa 1 indrone t 


( 2<*1<>2S6  A co*  I A jx>9  ) 

C Myt  (•<  y<  jx  A bop(  y)  > 1 A *<eop(y)<  1)^ 

~( text< bop(y)-l)*  text( eop( y)  + 1) > 1 J 
C Vyt  (#<y<jx  a eop(  y)  »•>  ) 

C o tr  ing(  bop(  y)  , eop<  y)  > *oh  a bop(y)>*I  a eop(y)0  1 
aVx(  (6<z<jx  a <»(*»y)) 

(*•<  bop(z)  *bop(y)  ) A (bop(z)<bop(y)  ^ eop<  z)  < cop*  y)  ) > 
( text! ftrst)*text( last)  A 1< • f irs t< »s tor t A f ins lh< * los »< * 1 
a s tr ing( f irs t , last)*ok  a start< finish 

A(flretal  V last'l  V ~( text( f Irs t- 1) • text! los t+ 1 )) ) } 


integer  It  coMwnt  loca 

logical  entryt 
entry! * trust 

C B21  A B22  A B23  A B24  a entry*  true  1 


for  1 • • 1 stop  1 until  Jx— 1 do 
begin 

if  < ( f irs t> "begin— of -pa 1 lndrone(  1) ) 

and  ( las t< "end— of— pa 1 lndrone( 1) ) ) then 
begin 

coBSsent  Palindrome  is  entirely  Included  in  a previously 
recorded  palindrome.  No  entry  required! 
entryt* fa loot 
end 

e lee 

begin 

if  ( ( begin— of— pa  1 indrome( i)  >*  first) 

and  (end— of_pa 1 lndrome( 1)  <»  last))  then 
begin 

end— of— palindrome(  1) :*6t 
comment  flag  sma 1 ler  palindrome! 
end  t 

end  i 

endt  comment  All  previously  recorded  palindrome* 

compared  with  last  input t 

C (entry* fa  las  A B27  A B28)  V 

[entry* true  a B21  a B22  a B23  a B24 
aV*(®<z<Jx  •=&  ( ~<bop(  z)  ■ f Irs  t) 
a bop(z)( first  e«p(z)< last)]  1 

If  entry  * true  than 
begin 

cosment  larger  than  all  previous  or  overlapping  or  dlsjolntt 

begin— of— pa  1 lndrome( jx) s *f Irs 1 1 

end-of— pal iudrone( jx) t* laatt 

JXOjX+l| 

endt 


C 20  10256  a ca*l  a jx>»  a B22  a B23  ) 
l 3y(6<y<jx  a iObop(y)Oetart  A f lnlsh<  "eop(  y)  < * 1 ) 

end  record— pa  1 Indrome  t 
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PROCEDURE  RECORD^-PAL INDROME 


This  assertion  is  a statement  that  either  entry-false  and  one 
set  of  predicates  apply,  or  that  entry-true  and  another  set 
apply.  If  entry-false,  no  further  action  will  be  taken  in  the 
procedure,  and  the  output  assertion  is  valid  at  this  point.  If 
entry-true,  the  input  assertion  is  still  valid,  and  the  entry 
for  the  current  palindrome,  which  will  be  the  jx-th  entry  in 
Mbop"  and  "eop",  will  only  be  disjoint  or  overlapping  to  all 
previous  entries  in  those  arrays  for  which  the  "eop"  entry  is 
not  zero. 

a.  Test  Data  Assertion  and  Verfication 

Test  data  were  selected  using  the  condition  table 
method  to  consider  all  predicates  which  were  considered  to 
bear  on  the  program  processing  with  respect  to  assertion  B26. 
The  applicable  condition  table  is  presented  below. 


Predicate 


eop(i)*0 

n 

n 

n 

n 

n 

n 

n 

n 

n 

y 

y 

y 

first>bop(i) 

y 

y 

y 

n 

n 

n 

n 

n 

n 

y 

n 

n 

first-bop(i) 

(n) 

(n) 

(n) 

y 

y 

y 

n 

n 

n 

(n) 

y 

n 

last<eop (i) 

y 

n 

n 

y 

n 

n 

y 

n 

n 

(n) 

(n) 

(n) 

last«eop(i) 

(n) 

y 

n 

(n) 

y 

n 

(n) 

y 

n 

(n) 

(n) 

(n) 

test  data: 

- 

first 

6 

5 

3 

1 

2 

1 

1 

1 

1 

6 

1 

1 

last 

7 

9 

4 

3 

3 

9 

2 

3 

5 

7 

3 

9 

i 

4 

4 

1 

2 

- 

3 

- 

- 

1 

1 

1 

1 

bop (i) 

1 

1 

2 

1 

2 

1 

2 

2 

2 

2 

1 

2 

eop(i) 

9 

9 

3 

4 

3 

5 

3 

3 

3 

0 

0 

0 

text 

B 

B 

B 

A 

* 

B 

* 

* 

B 

B 

A 

B 

jx 

5 

5 

2 

3 

- 

4 

- 

- 

3 

5 

3 

4 

correct 

action: 

X 

X 

- 

X 

X 

Y 

- 

Y 

Y 

Z 

Z 

- 

*These  compound  predicates  cannot  be 
satisfied  for  any  input  data  values. 


A:  aaaa  8:  baaabaaab 

X:  Set  entry  * false 

Y:  Set  eop(i)  * zero. 

Z:  None  required,  but  program  resets  eop(i)  * zero, 

which  is  permissable  (eop(i)  is  already  zero). 

As  an  action,  means  no  action  performed;  entry 
remains  true  and  a new  entry  will  be  made. 

The  preceding  condition  table  identifies  two  input  strings 
which  were  used  as  input  data  to  the  program;  intermediate  values 
of  program  values  were  inspected  on  each  iteration  of  the  for  loop 
in  procedure  "record^pal indrome"  to  determine  when  the  compound 
predicates  from  the  condition  table  were  satisfied  so  that  veri- 
fication of  the  correct  action  as  specified  in  the  table  could 
be  made.  The  correct  action  was  observed  for  each  test  data 
element. 


1S3 


MM 


mv*  - 


b.  Generalization  Assertion  and  Verification 

The  generalization  assertion  is  that  the  actions 
performed  by  the  procedure  are  totally  determined  by  the  five 
predicates  in  the  condition  table;  if  execution  of  the  for  loop 
body  performs  properly  for  the  identified  test  data  elements, 
it  performs  properly  for  all  data  satisfying  the  same  conjunctions 
of  the  five  predicates.  The  verification  offered  is  the  analysis 
forming  the  basis  for  the  condition  table  entries. 

c.  Proof  of  Synthesized  Assertion 

Since  predicate  B23  of  the  procedure  input  specifi- 
cation is  valid  at  the  entry  to  the  for  loop,  it  cannot  happen 
that  the  current  palindrome  (string  (first,  last))  both  includes 
a previous  entry  and  is  included  by  a different  previous  entry. 
Since  program  action  (either  entry:=false  or  eop(i) :*0)  is  taken 
only  when  one  of  these  conditions  exists,  repeated  execution 
from  "i"  equal  1 to  jx-1  of  the  loop  body  cannot  cause  an  unde- 
sirable result  such  as  setting  "entry"  to  false  and  also  setting 
eop(i)  to  zero  for  some  "i".  Thus  the  synthesized  assertion 
follows  from  the  test  data  and  generalization  assertions,  al- 
though a formal  proof  cannot  be  offered. 

3.  Synthesized  Assertion  B27-28: 


B27 : 


2<»A<*256  A ca m&  a jx>0  A B22  A B23 


B28:  3y(0<y<jx  a l<»bop (y) <-start  a finish<-eop(y) <-t) 

Assertion  B27-28  is  the  output  assertion  for  this  procedure. 

a.  Test  Assertion  and  Verification 

The  test  data  assertion  is  that  if  the  test  data 
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elements  identified  in  the  first  and  sixth  columns  of  the  con- 
dition table  used  for  assertion  B26  are  executed  to  the  proce- 
dure's termination,  the  output  specification  will  hold.  The 
correct  results  were  observed,  namely  that  for  the  column-one 
element  no  new  entries  were  made  to  the  arrays  "bop"  and  "eop", 
and  that  for  the  column-six  element  the  proper  (fourth)  entry 
was  made  in  the  arrrays;  in  both  cases  the  output  specification 
was  observed  to  hold. 

b.  Generalization  Assertion  and  Verification 

The  generalization  assertion  is  that  the  variable 
"entry"  divides  input  to  the  procedure  into  two  equivalence 
classes  and  that  proper  execution  of  one  element  of  each  class 
(as  observed  in  the  verification  of  the  test  data  assertion) 
ensures  proper  execution  for  the  entire  class. 

c.  Proof  of  Synthesized  Assertion 

The  synthesized  assertion  follows  from  the  test  data 
and  generalization  assertions;  however,  no  theorem  is  available 
to  formally  prove  the  sets  of  input  data  identified  are  in 
fact  equivalence  classes. 

This  verification  of  synthesized  assertion  B27-28  completes 
the  demonstration  of  correctness  of  procedure  "record«-palindrome". 
The  principle  of  distributed  correctness  has  been  applied  to 
show  the  correctness  of  the  main  program  from  the  correctness 
of  the  called  procedures. 


155 


BIBLIOGRAPHY 


1.  Belford,  P.C.,  J.  D.  Donahoo,  and  W.  J.  Heard,  "An  Evaluation 

of  the  Effectiveness  of  Software  Engineering  Techniques," 
IEEE  Comp con.  Fall  1977,  pp  259-67. 

2.  Black,  Rachel,  "Effects  of  Modern  Programming  Practices  on 

Software  Development  Costs,"  IEEE  Comp con.  Fall  1977, 
pp  250-53. 

3.  Boehm,  Barry  W. , "Software  and  Its  Impact:  A Quantitative 

Assessment,"  Datamation,  May  1973,  pp  48-59. 

4.  Boehm,  B.W.,  J.  R.  Brown,  and  M.  Lipow,  "Quantitative  Eval- 

uation of  Software  Quality,"  Proceedings  of  the  2nd 
International  Conference  on  Software  Engineering,  October 
■ 19'76  r pp"  5'9^oT: 

5.  Brooks.  Frederick  P. , The  Mythical  Man-Month,  Addison- 

Wesley , 1975.  ' 

6.  Brown,  John  R. , "Modern  Programming  Practices  in  Large  Scale 

Software  Development,"  IEEE  Compcon,  Fall  1977,  pp  254-58. 

7.  Culpepper,  L.  M. , "A  System  for  Reliable  Software,"  IEEE  Trans 

actions  on  Software  Engineering,  June  1975,  pp  174- 7JT. 

8.  Darringer,  John  A.,  and  James  C.  King,  "Applications  of 

Symbolic  Execution,"  Computer , April  1978,  pp  51-60. 

9.  Dijkstra,  Edsger  W.,  "Correctness  Concerns  and,  Among  Other 

Things,  Why  They  are  Resented,"  Proceedings  of  the  Inter- 
national  Conference  on  Reliable  Software,  ACM  SlGPLAN^ 

April  1975 ,'  pp  "5'4'6"-"5in 

10.  Dijkstra,  Edsger  W. , "Notes  pn  Structured  Programming,"  in 

Structured  Programming  (O.J.  Dahl,  E.W.  Dijkstra,  and 
C.A.k.  HoareJ .Academic  Press,  1972. 

11.  Fairley,  Richard  E.,"An  Experimental  Program-Testing  Facility, 

IEEE  Transactions  on  Software  Engineering,  December  1975, 
pp  350-57. 

12.  Fairley,  Richard  E.,  "Tutorial:  Static  Analysis  and  Dynamic 

Testing  of  Computer  Software,"  Computer,  April  1978, 
pp  14-23. 

13.  Floyd,  Robert  W.,  "Assigning  Meaning  to  Programs,"  Proceedings 

of  Symposia  of  Applied  Mathematics , American  Mathematical 
Society,  1967,  pp  19-32'. 


156 


— 


14.  Galler,  Matthew,  "Test  Data  as  an  Aid  in  Proving  Program 

Correctness,"  Communications  of  the  ACM,  May  1978, 
pp  368-75. 

15.  Gerhart,  Susan  L.,  and  L.  Yelowitz,  "Observations  of 

Fallibility  in  Applications  of  Modern  Programming  Metho- 
dologies," IEEE  Transactions  on  Software  Engineering, 
September  1976,  pp  195-207. 

16.  Goodenough,  John  B.,  et  al.,  "MAIDS  Information  Dynamics 

Technology  Requirements  Study,"  Final  Report,  Software 
Technology  Company,  April  1973. 

17.  Goodenough,  John  B.,  and  Susan  L.  Gerhart,  "Toward  a Theory 

of  Test  Data  Selection,"  IEEE  Transactions  on  Software 
Engineering , June  1975,  pp  156-73. 

18.  Hetzel,  W.C.,  ed. , Program  Test  Methods,  Prentice-Hall,  1973. 

19.  Hoare,  C.A.R.,  "Procedures  and  Parameters:  An  Axiomatic 

Approach,"  in  "Symposium  on  Semantics  of  Algorithmic  Lan- 
guages," Lecture  Notes  in  Mathematics,  Vol.  188,  Springer- 
Verlag,  1971,  pp  102-16. 

20.  Hoffman,  Heinz-Michael , "An  Experiment  in  Software  Error 

Occurrence  and  Detection,"  Master's  Thesis,  Naval  Post- 
graduate School,  June  1977. 

21.  Howden,  W.E.,  "Reliability  of  the  Path  Analysis  Testing 

Strategy,"  IEEE  Transactions  on  Software  Engineering, 
September  1976,  pp  ZU8-15. 

22.  Huang,  J.C. , "An  Approach  to  Program  Testing,"  Computing 

Surveys , September  1975,  pp  113-28.  ~ 

23.  Huang,  J.C.,  "Program  Instrumentation  and  Software  Testing," 

Computer , April  1978,  pp  25-32. 

24.  IBM  Corporation,  "Validation  and  Verification  Study," 

Structured  Programming  Series,  Vol.  XV,  Gaithersburg, 
Maryland,  July  1974  (Contract  F30602- 74-C-0186) . 

25.  London,  R.L.,  "A  View  of  Program  Verification,"  Proceedings 

of  the  International  Conference  on  Reliable  Software, 

ACM  STGNPLSN,  April  

26.  Manna,  Z. , and  R.  Waldinger,  "The  Logic  of  Computer 

Programming,"  IEEE  Transactions  on  Software  Engineering, 

May  1978,  pp  199-ZZ9. 

27.  McCabe,  Thomas  J. , "A  Complexity  Measure,"  IEEE  Transactions 

on  Software  Engineering,  December  1976,  pp  30d-Z0. 


157 


28.  Myers,  Ware,  "The  Need  for  Software  Engineering,"  Computer , 
February  1978,  pp  12-26. 


29.  Panzl,  David  J. , "Automatic  Software  Test  Drivers,”  Com- 

puter , April  1978,  pp  44-50. 

30.  Panzl,  David  J. , "Test  Procedures:  A New  Approach  to  Soft- 

ware Verification,"  Proceeding  of  the  2nd  International 
Conference  on  Software  Engineering,  October  1976,  pp  477-85. 

31.  Pimont,  Simone,  and  Jean-Claude  Rault,  "A  Software  Reliabil- 

ity Assessment  Based  on  Structural  and  Behavorial  Analysis 
of  Programs,"  Proceedings  of  the  2nd  International  Con- 
ference on  Software  Engineering,  October  1976,  pp  4^6-  71. 

32.  Ramamoorthy , C.V. , S.  F.  Ho,  and  W.T.  Chen,  "On  the  Auto- 

mated Generation  of  Program  Test  Data,"  IEEE  Transactions 
on  Software  Engineering,  December  1976,  pp  293-300. 

33.  Schneidewind,  N.F.  and  H.  M.  Hoffman,  "An  Experiment  in 

Software  Error  Data  Collection  and  Analysis,"  Proceedings 
of  the  6th  Texas  Conference  on  Computing  Systems,  November 
1977  , pp  4A1"-  4 A IT: 

34.  Whitaker,  W.A. , "A  Defense  View  of  Software  Engineering," 

Proceedings  of  the  2nd  International  Conference  on  Soft- 
ware Engineering,  October  l97o,  pp  35a-b2\ 


INITIAL  DISTRIBUTION  LIST 


No.  Copies 
2 


1.  Defense  Documentation  Center 
Cameron  Station 
Alexandria,  Virginia  22314 


2.  Library,  Code  0142  2 

Naval  Postgraduate  School 
Monterey,  California  93940 


3.  Department  Chairman,  Code  52  1 

Department  of  Computer  Science 
Naval  Postgraduate  School 
Monterey,  California  93940 


4.  Professor  Norman  F.  Schneidewind,  Code  52  Ss  1 

Department  of  Computer  Science 
Naval  Postgraduate  School 
Monterey,  California  93940 


5.  Professor  Donald  P.  Gaver,  Code  55  Gv  1 

Department  of  Operations  Research 
Naval  Postgraduate  School 
Monterey,  California  93940 


6.  LCDR  Carl  W.  Monk,  Jr.,  USN  1 

5355  Gainsborough  Drive 
Fairfax,  Virginia  22030 


159 


